嵌入式数据库在C工程里属于那种“平时不起眼、用起来真香”的组件。做上位机、设备端采集、离线分析这类项目时一旦涉及数据持久化和结构化查询你很快会发现自己写一个低配版“文件存档”不够用而部署一个独立数据库服务器又太重。嵌入式数据库恰好卡在中间数据库引擎直接链接进你的进程数据文件就在本地没有网络端口没有守护进程一行代码打开、读写、关库。这篇文章我就把两个真实项目里集成嵌入式数据库的过程完整拆一遍从选型、环境搭建到具体代码写法再到文档里不会写的坑最后聊一聊我踩过的最痛的几个问题。1. 嵌入式数据库在C项目里到底解决了什么问题1.1 三个真实场景让我决定引入它第一个场景是工业采集网关的配置与日志存储。设备端需要记录每台仪表的采集数据、报警事件和用户操作日志数据量不算大一天几万条但要求程序异常断电后数据不丢、查询方便。最初我用的是INI文件加结构体序列化配置字段少的时候勉强能用后来字段多了要按时间段筛选报警记录这套方案就彻底撑不住了。每次改动字段都要写一堆手动的版本兼容逻辑查询一段日志得把整个文件读进内存再遍历程序启动时更是慢得让人崩溃。第二个场景是离线分析工具。一个桌面端的小工具需要把人工录入的多组实验数据保存到本地下次启动时继续分析。实验数据带分组、标签、数值和时间戳还要支持按条件过滤和统计。当时我评估过MySQL——问题很明显客户端用户电脑上没有装MySQL就算装了也得处理账号权限、服务自启、端口冲突这些事软件交付时会把运维难度拉高一大截。嵌入式数据库直接把可执行文件和数据库文件绑在一起交给用户的就是一个exe加一个本地db文件打开即用。第三个场景是跨平台数据交换。我在一个项目里同时维护Windows和Linux两个平台程序需要从采集设备中导出数据包再在另一台机器上导入分析。用自定义二进制格式需要自己维护解析器和校验逻辑两边版本对不上就废了。后来统一切换成嵌入式数据库存储数据包平台间拷贝的只是一个数据库文件目标程序打开它、按SQL查询即可。省掉的不止是序列化代码还有大量的沟通成本和版本兼容问题。1.2 嵌入式数据库的边界在哪里讲完引入动机也得说清楚边界不然容易用错地方。嵌入式数据库适合的是“单机、单进程、数据量在GB级别以下、需要结构化或半结构化存储”的场景。它不适合做高并发的在线服务不适合做分布式集群也别指望它能承载几十亿行的在线查询。更直白地说嵌入式数据库和服务器数据库的取舍很像“工具箱和流水线”的关系你要在家里修个东西工具箱够了你要在工厂批量组装几百台机器就需要流水线。我见过有人把SQLite当Oracle用让几十个客户端通过网络文件系统共享同一个数据库文件结果不断报锁定和损坏这就是选型没想清楚。嵌入式数据库默认假设你的进程是唯一访问者这个前提一旦被破坏各种诡异问题就会冒出来。认清这一点后面所有设计都会顺很多。2. 选型对照SQLite、LevelDB、RocksDB、DuckDB怎么挑2.1 四种候选的定位差异集成之前最该花时间的其实是选型。嵌入式数据库看似冷门真正列出来也不少SQLite、LevelDB、RocksDB、DuckDB、LMDB、Berkeley DB等。我的经验是先按“数据模型”分大类再按“并发模型”做过滤最后看集成难度。SQLite是关系型嵌入式数据库用SQL语言操作支持标准建表、索引、事务、视图适合需要复杂查询和过滤的场景。LevelDB是键值型存储由Google开源单机写入性能极高按Key排序存储适合做缓存、消息队列后端、索引落地这类的KV任务。RocksDB是LevelDB的增强版针对多核、SSD和大数据量做了大量优化但集成复杂度明显更高一般是在需要服务化、大规模落盘时才值得引入。DuckDB则是一个列式分析型嵌入式数据库主打在单个进程内跑复杂的OLAP查询和SQLite同期比较时它更偏分析负载。从工程感知上讲SQLite和LevelDB覆盖了我至少九成的嵌入式需求。前者解决“要用SQL查”的问题后者解决“我要高性能键值写入”的问题。DuckDB近年很热门但它在C工程里常见用途是替代Pandas做本地数据探索属于分析工具而非设备端存储集成时参考意义大于实战意义。2.2 我的选择逻辑与推荐组合我在实际选型时是这么决策的维度SQLiteLevelDB说明数据模型关系型SQL键值型Key-Value先看业务查询复杂度事务能力ACID完整支持WriteBatch原子写多键合并写用WriteBatch很顺手并发模型多读单写库级锁单进程单实例多进程访问LevelDB文件会直接损坏查询能力SQL强大可加索引只能按Key或迭代区间扫描二级查询需业务层自建索引构建复杂度单文件编译极低需要编译依赖库两者都比RocksDB轻得多典型场景配置、日志、设备数据缓存、索引、消息持久化同一进程可以两者混用我的原则可以总结成一句话业务上需要“按条件查”选SQLite业务上只需要“按Key取、按区间迭代”选LevelDB。如果你在主键上做点查询但需求里有明显的范围扫描、聚合统计、多条件过滤硬用LevelDB会把自己逼疯——你要手动维护各种索引结构那工作量比换个数据库大得多。我的推荐组合也很有意思一个采集程序里元数据和查询需求用SQLite存最近N条的原始采集序列用LevelDB存。SQLite负责给人看的结构化信息LevelDB负责给机器读的高速缓冲两者不冲突。这个组合在项目里跑了很久几乎没有出现过阵亡级故障。3. 用CMake把SQLite集成进C工程3.1 看起来最笨但最稳的集成方式选SQLite之后集成方式是第一个要拍的板。SQLite官方提供两种主流接入方式一种是使用系统包管理工具安装比如apt install libsqlite3-dev另一种是把官方合并后的“amalgamation”源文件直接放进工程也就是sqlite3.c和sqlite3.h这两个文件。我强烈推荐第二种特别是你的产品要交付给别人编译的时候。原因很简单合并版文件不依赖第三方库版本动作完全在你自己工程的控制中任何人拿到源码都能编译出完全一致的库行为。系统包管理器版本在不同机器上可能不一致某些老Linux发行版上的SQLite版本还没有WAL模式、没有VACUUM INTO这些差异排查起来非常烦。我在Windows上用vcpkg装过一次SQLite结果拉到的版本和自己写代码的特性预期不一致当时排查了整整一下午。用CMake接入只需要把这些源文件加进目标即可cmake_minimum_required(VERSION 3.16) project(embedded_db_demo CXX) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) add_executable(demo_app main.cpp third_party/sqlite3.c third_party/sqlite3.h ) target_include_directories(demo_app PRIVATE ${CMAKE_CURRENT_SOURCE_DIR}/third_party ) # Windows下需要链接动态运行时库 if(WIN32) target_compile_options(demo_app PRIVATE /EHsc) endif()注意一个细节编译sqlite3.c时默认情况下它会把线程模式设为串行保证多线程环境下数据库句柄可以被安全使用。如果你的项目是单线程跑那没问题但如果你显式定义SQLITE_THREADSAFE0希望提速就必须想清楚自己能否保证所有调用都在同一个线程里。这个宏一旦设错多线程踩踏会直接导致表损坏不是报个错那么简单。3.2 初始化解锁连接、权限与配置项接入之后第一件事是建立数据库连接。这里值得认真读一下sqlite3_open_v2的第三个参数它不像第一眼看上去那么随意#include sqlite3.h sqlite3* db nullptr; int rc sqlite3_open_v2( app_data.db, // 文件路径 db, SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE | SQLITE_OPEN_FULLMUTEX, nullptr // 默认VFS ); if (rc ! SQLITE_OK) { // 此时通常需要 sqlite3_errmsg(db) 看具体失败原因 sqlite3_close(db); throw std::runtime_error(open database failed); }SQLITE_OPEN_FULLMUTEX意味着数据库连接可以在多线程里被并发调用SQLite内部会自动加锁。注意即便有了这个标志一个连接被多个线程同时执行写事务阻塞、串行、超时仍然会存在它只保证库内部结构不会被踩坏不保证业务上的并发时序。随后我会统一设置几个关键的PRAGMA参数这些建议放在每次打开数据库后立刻执行static void configure_db(sqlite3* db) { sqlite3_exec(db, PRAGMA journal_modeWAL;, nullptr, nullptr, nullptr); sqlite3_exec(db, PRAGMA synchronousNORMAL;, nullptr, nullptr, nullptr); sqlite3_exec(db, PRAGMA busy_timeout5000;, nullptr, nullptr, nullptr); sqlite3_exec(db, PRAGMA foreign_keysON;, nullptr, nullptr, nullptr); }WAL模式对读多写少的场景尤其友好读操作不阻塞写操作写操作不阻塞读操作。synchronousNORMAL则是在WAL模式下推荐的折中方案它在性能和崩溃安全之间取得了一个很实用的平衡点进程崩溃不会丢数据操作系统崩溃时最多丢最近几个事务。busy_timeout的意义在于当两个写入事务撞到一起SQLite会等待而不是立即返回SQLITE_BUSY。建表也建议走sqlite3_exec这是最直白的一类用法const char* schema RSQL( CREATE TABLE IF NOT EXISTS device_log ( id INTEGER PRIMARY KEY AUTOINCREMENT, device_id TEXT NOT NULL, level INTEGER NOT NULL DEFAULT 0, message TEXT, created_at INTEGER NOT NULL ); CREATE INDEX IF NOT EXISTS idx_log_device_time ON device_log(device_id, created_at); )SQL; char* errmsg nullptr; rc sqlite3_exec(db, schema, nullptr, nullptr, errmsg); if (rc ! SQLITE_OK) { std::string msg errmsg ? errmsg : unknown error; sqlite3_free(errmsg); sqlite3_close(db); throw std::runtime_error(create schema failed: msg); }这里有个很多人会忽略的细节创建索引时索引列顺序不是随便写的。上面的idx_log_device_time把device_id放前面、created_at放后面它首先能支持“按设备ID过滤后按时间排序”的查询如果你单独按时间维度查这个索引实际帮不上忙。这属于基本的组合索引设计在嵌入式数据库上同样奏效。3.3 拿稳prepared statement别碰sqlite3_exec拼SQL的雷所有涉及用户输入的写操作我从不推荐用sqlite3_exec直接拼SQL字符串原因就是你猜到的那个——SQL注入在设备端同样存在更现实的问题是字符串拼接对特殊字符和二进制内容极不友好。正确的做法是用prepared statement加参数绑定写起来多两行收益是安全又稳。插入数据是一个最典型的例子const char* sql RSQL( INSERT INTO device_log(device_id, level, message, created_at) VALUES (?1, ?2, ?3, ?4); )SQL; sqlite3_stmt* stmt nullptr; rc sqlite3_prepare_v2(db, sql, -1, stmt, nullptr); if (rc ! SQLITE_OK) { throw std::runtime_error(sqlite3_errmsg(db)); } sqlite3_bind_text(stmt, 1, deviceId.c_str(), -1, SQLITE_TRANSIENT); sqlite3_bind_int(stmt, 2, level); sqlite3_bind_text(stmt, 3, message.c_str(), -1, SQLITE_TRANSIENT); sqlite3_bind_int64(stmt, 4, currentTimestamp); rc sqlite3_step(stmt); if (rc ! SQLITE_DONE) { throw std::runtime_error(sqlite3_errmsg(db)); } sqlite3_finalize(stmt);几个容易出事的细节参数索引从1开始不是0这个是SQLite一个非常经典的坑——把?1写成?0SQLite不会报错它把你绑定的参数当作类型异常或静默忽略查错特别隐蔽。SQLITE_TRANSIENT告诉SQLite你的字符串指针在完成插入前可能会失效需要内部拷贝一份如果你能保证字符串在该步调用期间一直存活可以用SQLITE_STATIC减少一次拷贝但风险自负。查询我习惯用循环step的方式const char* query RSQL( SELECT id, device_id, level, created_at FROM device_log WHERE device_id ?1 AND created_at ?2 ORDER BY created_at DESC LIMIT 100; )SQL; sqlite3_stmt* stmt nullptr; sqlite3_prepare_v2(db, query, -1, stmt, nullptr); sqlite3_bind_text(stmt, 1, targetDevice.c_str(), -1, SQLITE_TRANSIENT); sqlite3_bind_int64(stmt, 2, beginTime); while (sqlite3_step(stmt) SQLITE_ROW) { int id sqlite3_column_int(stmt, 0); const unsigned char* deviceId sqlite3_column_text(stmt, 1); int level sqlite3_column_int(stmt, 2); sqlite3_int64 created sqlite3_column_int64(stmt, 3); // 处理一行业务数据 } sqlite3_finalize(stmt);强烈建议把prepare、bind、column、finalize封装成轻量的辅助函数但不要过度封装成“万能数据库层”。我在早期项目里追求过完美抽象搞出一大堆QueryBuilder、ResultSet后来发现真正好用的时候反而是裸SQL可控可调的时候。封装到“安全地执行SQL并取结果”这层就停再往上都是过度设计。3.4 事务与批量插入一万条数据从六十秒到半秒设备端经常遇到批量写入比如一次性缓存了上千条采集记录。一条条INSERT的情况下每次写都是一次独立事务每一次都包含磁盘同步慢是必然的。解决办法是显式开启事务sqlite3_exec(db, BEGIN IMMEDIATE;, nullptr, nullptr, nullptr); // 循环执行INSERT for (const auto record : records) { sqlite3_bind_text(stmt, 1, record.deviceId.c_str(), -1, SQLITE_TRANSIENT); sqlite3_bind_int(stmt, 2, record.level); sqlite3_bind_text(stmt, 3, record.message.c_str(), -1, SQLITE_TRANSIENT); sqlite3_bind_int64(stmt, 4, record.timestamp); sqlite3_step(stmt); sqlite3_reset(stmt); // 重置stmt复用不要每行都重新prepare } sqlite3_exec(db, COMMIT;, nullptr, nullptr, nullptr);重点提醒复用同一个stmt时必须在每次绑定新参数前调用sqlite3_reset而不是sqlite3_finalize。reset把语句状态重置到可重新绑定参数的状态不会释放语句如果你在循环里一直finalize再prepare等于放弃了预编译带来的性能优势。从实测数据看10000条数据逐条自动提交大约需要几十秒手动开启事务加stmt复用的方式在同一块SSD上能压到0.3到0.6秒差距是两个数量级。4. 集成LevelDB另一种“零依赖”路径4.1 拿到源码、翻出CMake构建文件SQLite解决的是查询问题但当业务退化成“只要按Key存取”时每次都要写SQL就显得多余。LevelDB这种嵌入式键值库更适合这种上下文写多读多、Key有序性要求高、没有复杂关联查询。集成LevelDB比集成SQLite多一步——它需要构建库。我通常在CMake里直接拉源码编译include(FetchContent) FetchContent_Declare( leveldb GIT_REPOSITORY https://github.com/google/leveldb.git GIT_TAG v1.23 ) set(LEVELDB_BUILD_TESTS OFF CACHE BOOL FORCE) set(LEVELDB_BUILD_BENCHMARKS OFF CACHE BOOL FORCE) FetchContent_MakeAvailable(leveldb) target_link_libraries(demo_app PRIVATE leveldb)构建完LevelDB之后头文件路径在源码目录的include目录下核心接口都在leveldb/db.h里。整个库包含读写、删除、迭代、快照、批量原子写这几种基本能力学起来比SQLite还快。4.2 写CRUD顺便讲清Slice的坑LevelDB读写操作如下#include leveldb/db.h leveldb::DB* db nullptr; leveldb::Options options; options.create_if_missing true; options.compression leveldb::kSnappyCompression; leveldb::Status status leveldb::DB::Open(options, kv_data, db); if (!status.ok()) { throw std::runtime_error(status.ToString()); } // 写入 status db-Put(leveldb::WriteOptions(), device:001:temp, 25.6); if (!status.ok()) { /* 处理错误 */ } // 读取 std::string value; status db-Get(leveldb::ReadOptions(), device:001:temp, value); if (status.IsNotFound()) { // Key不存在这是正常分支 } else if (!status.ok()) { // 真正的错误 } // 删除 status db-Delete(leveldb::WriteOptions(), device:001:temp);第一眼看上去很简单但真正危险的地方藏在那个字符串Key里。LevelDB的Put和Get接受的Key、Value都是leveldb::Slice类型Slice本质上是“指针长度”它不会拷贝你传入的字符串内容。这就意味着你的字符串对象在调用结束后必须仍然有效否则Slice持有的指针会悬空。最常见的错法是传了一个临时string进去// 这是错误写法 std::string key temp; db-Put(leveldb::WriteOptions(), leveldb::Slice(key.c_str(), key.size()), 25.6);等等这样写其实是对的因为Slice构造时没有拷贝。真正的反例是把std::string(temp)直接临时对象传入然后调用返回后临时对象销毁Slice还在被持有。LevelDB的文档里明确写了这个坑但每隔一段时间还是有人踩。用LevelDB之前你的代码风格必须养成一个习惯切片生命周期和底层字符串生命周期严格绑定。4.3 WriteBatch、Iterator与自定义比较器和SQLite的定位分界批量写不是逐条调用Put而是用WriteBatch攒一批原子操作leveldb::WriteBatch batch; batch.Put(device:001:temp, 25.6); batch.Put(device:001:humi, 60.1); batch.Delete(device:001:old_key); leveldb::Status s db-Write(leveldb::WriteOptions(), batch);WriteBatch保证这批写操作要么全部生效要么全部不生效。这个能力和SQLite的事务等价但LevelDB没有回滚和嵌套事务等复杂语义。遍历数据用迭代器std::unique_ptrleveldb::Iterator it( db-NewIterator(leveldb::ReadOptions()) ); it-Seek(device:001:); // 跳到指定区间起点 while (it-Valid() it-key().starts_with(device:001:)) { std::string key it-key().ToString(); std::string value it-value().ToString(); it-Next(); }注意迭代器里返回的Slice在迭代器移动后会失效所以如果想保存必须立即ToString拷贝。这个是我做过一次“指针悬挂导致数据全乱”后总结出来的初学绕不过去。选型分界也很清楚如果业务只是“一个Key接一个Value顶多前缀扫描”用LevelDB省心省力。你的Key设计就是最核心的一层“索引”。实际项目中我会把LevelDB做成一块“热数据暂存区”写入吞吐高、读取按前缀快由后台定时把它合并落盘到SQLite做长期归档。这个架构在采集类项目里相当实用。5. 踩坑实录并发访问、崩溃定位与编译环境5.1 SQLITE_BUSY和多线程连接的经典命案用SQLite多线程最常见的第一课就是SQLITE_BUSY。它的字面意思是“数据库文件被另一个连接锁住了”绝大多数情况是同一个进程里两个连接试图同时写同一个库文件。我见过最迷惑的案例是每隔几分钟稳定复现SQLITE_BUSY而且只在业务高峰期出现看起来完全随机。排查办法分三步。先确认是不是自己的线程模型同一个连接如果被多个线程共用且开启了FULLMUTEXSQLite内部的锁会串行化所有操作一般不至于出BUSY真正的BUSY大多来自多个独立连接。再确认是不是有别的进程打开着这个文件比如你用DBeaver或者Navicat看了一眼库文件你的程序再写就会出现BUSY。最后检查WAL模式下是否有残留的-wal文件挂在旁边。-shm和-wal文件的存在会影响数据库打开状态。处理方案就两条把PRAGMA busy_timeout调大比如5000ms让SQLite在锁冲突时等待而不是立即抛错从架构上保证写事务串行化比如全局锁、线程池单写线程。我用过最多的是这两种组合实测稳定。5.2 WAL模式的三文件陷阱和checkpoint打开WAL模式后你会发现目录里多了两个文件xxx.db-wal和xxx.db-shm。这不是数据损坏是WAL的日志和共享内存文件。但很多人交付时会漏拷贝这两个文件导致换一台机器后数据库数据“少了”。WAL模式下数据实际存在三个位置主db文件、-wal日志文件、-shm共享映射。正常打开关闭数据库后最后一段WAL内容会被合并回主文件-wal会清理。但如果你程序不是优雅关闭比如直接杀进程-wal文件残留下次打开时SQLite会自动从-wal恢复数据。问题出在备份场景如果你只拷贝db文件不拷贝-wal那你丢的就是最近一批未checkpoint的数据。备份时最安全的做法是执行一次PRAGMA wal_checkpoint(TRUNCATE);把-wal合并回主文件后再拷贝。更省心的办法是用SQLite的在线备份API也就是sqlite3_backup_init系列接口。5.3 Access Violation c0000005这类崩溃怎么查C集成数据库时最容易遇见的崩溃就是访问违例Windows上表现为0xc0000005。我一次遇到这类崩溃是在跨语言调用场景C#调用我封装的C DLLDLL内部打开了SQLite数据库并返回查询结果结果调用到一半直接崩掉。如果你也遇到访问违例第一怀疑对象永远是“对象生命周期”。C侧把内存释放了C#侧还在用或者C#侧把字符串传给C时编码不对导致C拿到一个被截断或非法的缓冲。排查时用三个手段开调试器看异常发生点看是不是在sqlite3_step内部检查所有跨语言传参的编码Windows默认UTF-16C函数是UTF-8必须显式转换最后检查数据结构对齐C#里用UnmanagedType指定一下。这类崩溃还有一个隐藏源你用动态库链接了系统自带的SQLite而DLL入口点没有显式加载依赖库或者动态库版本和头文件版本不一致。函数签名对不上调用时跳到一个非法地址表现同样是一个Access Violation。经验是跨语言联合调试时不要自作聪明用官方统一版本、用编译期确认过A的稳定方案就好。5.4 VS Code配置C/C环境时的include路径和宏坑很多人在VS Code里编译嵌入式数据库的例子时会卡在编译阶段报错大多是找不到sqlite3.h、类型未定义。这不是代码问题是IntelliSense和编译器没找到头文件。推荐的做法是不要用VS Code自带的那个小齿轮直接用CMake Tools插件。打开c_cpp_properties.json在includePath里加上third_party目录。记得在defines里加上编译宏比如SQLITE_THREADSAFE1不然IntelliSense可能提示某些接口不存在但实际gcc编译是通过的。另一个常踩的坑是Linux和Windows的差异。在Windows上使用gcc编译时出现M_PI未定义这类莫名其妙的问题通常是编译器版本对C标准的实现差异或者某个头文件里没有定义_USE_MATH_DEFINES。这个问题和数据库本身无关但会被误以为是集成失败。遇到时首先要看具体报错是预处理器宏还是链接符号再逐步打开编译诊断日志。VS Code的编译输出窗口里能看到完整命令行把命令行复制出来在终端手动跑一遍往往几分钟就能定位问题。6. 数据文件的长期演进与备份策略6.1 表结构升级别硬来用版本号管理数据库文件一旦落到用户设备上就不能随意改表结构了。我习惯在SQLite里用一个PRAGMA user_version来管理schema版本int currentVersion 0; sqlite3_int64 userVersion 0; sqlite3_exec(db, PRAGMA user_version;, callback_for_version, userVersion, nullptr);启动时先读到版本号再逐级迁移。如果当前版本是1迁移脚本就是“新增一列、建一个新索引、更新一条数据”如果是从版本1直接跳到版本3不能跳过中间步骤必须依次执行1到2、2到3的迁移脚本。每段迁移都放进一个显式事务失败了回滚并输出错误。这个“版本号事务化迁移”的模式虽然简单但救过我很多次至少不会出现“我明明改了代码老数据打开却报错”的问题。备份策略上SQLite建议用VACUUM INTO或backup API做热备而不是冷拷贝文件。冷拷贝时如果有-wal残留备份就是不完整的。LevelDB更严格官方规定同一时间只允许一个进程打开同一个数据库目录多进程并发直接可能导致数据库损坏。热备LevelDB一般是先短暂暂停写入然后拷贝目录或者用迭代器把数据遍历出来重新写入备份。6.2 性能优化方向别一上来就调PRAGMA遇到性能问题我不建议一上来就查“SQLite性能优化20例”。最常见的痛点是查询慢而查询慢的根源通常是索引缺失或者查询语句没走索引而不是PRAGMA没调对。我用EXPLAIN QUERY PLAN看一条查询是否命中了索引一个简单的例子EXPLAIN QUERY PLAN SELECT * FROM device_log WHERE device_id dev01 AND created_at 1000;如果查询计划里有SCAN而没有SEARCH USING INDEX那就是索引没建到位。调整索引列顺序、减少返回列效果比任何PRAGMA都要明显。写入性能的调优方向则不太一样先看是否用了手动事务再看是否用了WAL模式最后才考虑编译选项。我在前面提过手动事务带来的提升是数量级的调PRAGMA之前先把这层做好。如果你真的到了要压极限的性能阶段可以考虑给sqlite3.c加几个安全但有效的编译宏比如SQLITE_DEFAULT_WAL_SYNCHRONOUS1、SQLITE_TEMP_STORE2但这类优化必须带着充分测试不要盲目照搬网络上的参数。6.3 长期运行后的文件膨胀问题数据库文件越用越大是嵌入式数据库老用户常见的话题。SQLite删除数据不一定释放空间给操作系统文件尺寸可能保持只增不减。这对桌面端、设备端非常敏感用户会来问“数据库文件怎么比我存的数据大这么多”。常规做法是执行VACUUM重建数据库文件释放无用空间。但VACUUM需要临时文件空间不足的嵌入式设备上要尤其小心而且它会把整个文件重写一遍耗时较长。经验做法是尽量在设计阶段避免频繁删除追加的结构使用INTEGER PRIMARY KEY的自增ID减少页碎片。真需要频繁删除的老化数据就改用按时间分表按月建表每个月创建一张新表老表到点直接DROP比VACUUM高效得多。最后一个技巧如果你的数据库文件经常是碎片化的检查是否启用了自动增量PRAGMA auto_vacuumINCREMENTAL配合PRAGMA incremental_vacuum能在系统空闲时逐步回收页面好处是不用重写整个文件。代价是每次删除操作会多做点额外工作适合写多删少、长期运行的场景。最后分享一点个人经验。我把嵌入式数据库集成进C项目前后绕了不少弯路早期最大的教训就是“一上来就封装万能数据库层”。SQLite和LevelDB这类库本身接口设计已经足够简洁真正的复杂性从来不在API而在并发控制、数据生命周期和文件备份。后来我所有项目都先把裸SQL和裸KV写好、跑通、测稳再抽象出极薄的一层业务封装。还有一个小技巧值得记住开发阶段打开SQLite的sqlite3_trace_v2把每条SQL和耗时打出来发现性能瓶颈的直觉准确很多LevelDB则可以用leveldb::Options::info_log指定日志路径看到合并与写入的调度日志排查写放大问题时会很有方向。这种“先跑裸库、再调业务层”的做法我推荐所有做C集成的朋友试一次会省下很多后面查诡异bug的时间。
