15、序列化与数据库：将序列化数据存入SQLite、BLOB字段的使用

说实话，很多嵌入式工程师做数据持久化时，第一反应就是写文本文件或者CSV。但我在实际项目中遇到过几次这样的尴尬：数据量一大，文件解析慢得要命；结构体一改，旧文件全得重写解析器。后来我学乖了——直接用SQLite，把序列化后的二进制数据塞进BLOB字段里。这招儿，真香。

为什么选SQLite + BLOB？

你想想看，嵌入式系统里最头疼的是什么？资源受限、断电风险、数据一致性。SQLite本身就是为嵌入式设计的，一个库文件搞定全部，不需要独立的数据库服务进程。而BLOB（Binary Large Object）字段，说白了就是存二进制大块头的专用字段。

我个人习惯把序列化后的数据直接扔进BLOB，而不是拆成多个字段存。为什么？

• 结构灵活：结构体改了，只要序列化/反序列化函数同步更新，数据库表结构不用动
• 读写高效：一次IO操作搞定整个对象，不用拼SQL拼接几十个字段
• 类型安全：二进制格式天然避免文本解析的坑，比如浮点数精度丢失

实战：从结构体到SQLite BLOB

先看一个典型的结构体。假设我们要存传感器数据：

// sensor_data.h
#pragma pack(push, 1)
typedef struct {
    uint32_t timestamp;     // 时间戳
    float    temperature;   // 温度
    float    humidity;      // 湿度
    uint8_t  status;        // 状态标志
    uint16_t crc;           // 校验值
} SensorData;
#pragma pack(pop)

注意我用了 #pragma pack(push, 1)。为什么？因为结构体默认有内存对齐，直接memcpy到BLOB再读回来，字段位置可能对不上。我在项目中就吃过这个亏——结构体里有个uint32_t，对齐后中间多了3个填充字节，反序列化出来全是乱码。嗯，从那以后我养成了习惯：序列化用的结构体，一律1字节对齐。

序列化与SQLite写入

序列化本身很简单，就是memcpy。但写入SQLite时，有几个关键点要注意：

#include <sqlite3.h>
#include <string.h>

int save_sensor_data(sqlite3 *db, const SensorData *data) {
    sqlite3_stmt *stmt;
    const char *sql = "INSERT INTO sensor_records (data_blob) VALUES (?);";
    
    // 准备语句
    if (sqlite3_prepare_v2(db, sql, -1, &stmt, NULL) != SQLITE_OK) {
        return -1;
    }
    
    // 序列化：直接把结构体当二进制数据绑定
    // 注意：SQLITE_TRANSIENT 告诉SQLite在内部拷贝数据
    sqlite3_bind_blob(stmt, 1, data, sizeof(SensorData), SQLITE_TRANSIENT);
    
    // 执行
    int rc = sqlite3_step(stmt);
    sqlite3_finalize(stmt);
    
    return (rc == SQLITE_DONE) ? 0 : -1;
}

这里有个细节：SQLITE_TRANSIENT。如果你传的是栈上的临时变量，SQLite执行完sqlite3_step后，这个内存可能就释放了。用SQLITE_TRANSIENT，SQLite会在内部拷贝一份。如果你传的是堆上持久的内存，可以用SQLITE_STATIC，省一次拷贝，但你要保证内存直到sqlite3_step完成前都有效。

反序列化与SQLite读取

读回来同样直接：

int load_sensor_data(sqlite3 *db, int record_id, SensorData *out) {
    sqlite3_stmt *stmt;
    const char *sql = "SELECT data_blob FROM sensor_records WHERE rowid = ?;";
    
    if (sqlite3_prepare_v2(db, sql, -1, &stmt, NULL) != SQLITE_OK) {
        return -1;
    }
    
    sqlite3_bind_int(stmt, 1, record_id);
    
    int rc = sqlite3_step(stmt);
    if (rc == SQLITE_ROW) {
        // 直接获取BLOB指针，memcpy到结构体
        const void *blob = sqlite3_column_blob(stmt, 0);
        int blob_size = sqlite3_column_bytes(stmt, 0);
        
        if (blob_size != sizeof(SensorData)) {
            // 数据大小不匹配，可能是版本不一致
            sqlite3_finalize(stmt);
            return -2;
        }
        
        memcpy(out, blob, sizeof(SensorData));
        sqlite3_finalize(stmt);
        return 0;
    }
    
    sqlite3_finalize(stmt);
    return -1;
}

看到没？反序列化就是memcpy回来。但这里我加了个大小检查——blob_size != sizeof(SensorData)。为什么？因为如果程序升级了，结构体变了，旧数据的大小可能对不上。我建议在结构体里加个版本号字段，或者存一个magic number做校验。

BLOB字段的避坑指南

我用SQLite BLOB踩过的坑，列出来给你参考：

问题	原因	解决方案
结构体对齐不一致	不同编译器默认对齐方式不同	使用 #pragma pack(push, 1)
字节序问题	大端/小端平台不兼容	序列化时统一转成网络字节序
结构体版本变更	新增字段后旧数据无法读取	加入版本号字段，做兼容处理
BLOB大小限制	SQLite默认BLOB上限1GB	大对象分块存储，或用增量序列化

进阶：批量读写与事务

如果你要存大量传感器数据，一条一条INSERT太慢了。我建议用事务包装：

int save_batch(sensor_data *db, SensorData *data_array, int count) {
    sqlite3_exec(db, "BEGIN TRANSACTION;", NULL, NULL, NULL);
    
    for (int i = 0; i < count; i++) {
        if (save_sensor_data(db, &data_array[i]) != 0) {
            sqlite3_exec(db, "ROLLBACK;", NULL, NULL, NULL);
            return -1;
        }
    }
    
    sqlite3_exec(db, "COMMIT;", NULL, NULL, NULL);
    return 0;
}

实测下来，1000条数据，不用事务要3秒多，用了事务不到0.1秒。差距就是这么大。

SVG：序列化数据入库流程

性能实测数据

我在一个ARM Cortex-M4项目上做过对比测试，存1000条传感器记录：

存储方式	写入时间	读取时间	存储空间
文本CSV	4.2秒	3.8秒	48KB
SQLite + 多字段	1.5秒	0.9秒	32KB
SQLite + BLOB	0.8秒	0.3秒	28KB

BLOB方案不仅快，而且省空间。因为二进制格式没有文本的冗余字符，也没有字段名存储开销。

好了，关于SQLite BLOB存序列化数据，核心就是这些。记住：对齐、版本、字节序，这三个坑绕过去，剩下的就是memcpy的快乐了。

---

公众号:蓝海资料掘金营，微信deep3321