SQLite是一个广受欢迎的嵌入式关系型数据库，它不需要独立的服务进程，整个数据库就是一个文件，因此被大量应用于手机、路由器、智能家居、工业控制等嵌入式设备中。但在资源受限的环境下，工程师最关心的问题往往是：SQLite到底要吃掉多少内存？库本身有多大？对Flash的写入寿命有没有影响？本文将从内存占用、存储体积、CPU与I/O开销三个角度展开分析，并给出针对性的裁剪和优化方案。
一、SQLite的内存占用机制
SQLite的内存消耗主要分为三部分：页缓存（Page Cache）、连接对象与语句对象的基础开销，以及排序、索引等操作产生的临时内存。理解这三部分的分配规则，是评估内存占用的前提。
页缓存是最大头的开销。SQLite以页为单位读写数据库文件，默认页大小为4096字节，页缓存默认上限约为2000个页，也就是接近2MB的缓存空间。这在PC上不算什么，但在只有几MB RAM的嵌入式设备上完全是灾难。好在可以通过sqlite3_config(SQLITE_CONFIG_PAGECACHE)或PRAGMA cache_size来精确控制缓存大小，例如设置为64个页，内存占用就能压到256KB以内。需要注意的是，缓存太小会显著增加磁盘I/O次数，需要根据实际读写模式权衡。
除了页缓存，每个数据库连接对象本身大约占用几十KB的堆内存（取决于编译选项），每个未finalize的语句对象也会持有若干KB。临时内存主要出现在ORDER BY、GROUP BY、创建索引等需要排序的场景，默认上限由SQLITE_DEFAULT_PCACHE_INITSZ和PRAGMA soft_heap_limit控制。一个实用建议是：在嵌入式初始化阶段统一调用sqlite3_config(SQLITE_CONFIG_HEAP, ...)，让SQLite使用一块固定的静态内存池，避免运行时堆碎片。
/* 嵌入式场景下配置固定内存堆的典型写法 */
static char sqlite_heap[256 * 1024]; /* 256KB 静态内存池 */
sqlite3_config(SQLITE_CONFIG_HEAP, sqlite_heap, sizeof(sqlite_heap), 8);
sqlite3_config(SQLITE_CONFIG_LOOKASIDE, 512, 16); /* 减小lookaside槽位 */
sqlite3_initialize();
/* 打开数据库后限制页缓存 */
sqlite3_open("data.db", &db);
sqlite3_exec(db, "PRAGMA cache_size = 64;", 0, 0, 0);
实践表明，经过上述配置后，一个仅执行简单增删改查的SQLite实例，稳态内存占用可以控制在150KB到300KB之间。如果目标芯片的RAM低于64KB，就建议放弃SQLite，改用更轻量的键值存储方案。
二、库体积与编译裁剪
SQLite官方 amalgamation 源码全量编译后的库体积通常在700KB到1.2MB之间（取决于平台和编译器），对于Flash只有几MB的嵌入式设备来说压力不小。好消息是SQLite提供了大量编译时开关，可以大幅裁剪不用的功能模块。
最常用的裁剪选项是SQLITE_OMIT_*系列宏。例如如果你的应用从不需要全文检索，可以定义SQLITE_OMIT_COMPLETE、SQLITE_OMIT_DECLTYPE、SQLITE_OMIT_PROGRESS_CALLBACK等；禁用FTS5、JSON扩展和R树模块可以再省下上百KB。此外，把线程模式设为单线程（SQLITE_THREADSAFE=0）能移除所有互斥锁代码，这在单任务裸机或RTOS环境下完全安全。
/* 编译裁剪示例：适合极简嵌入式场景 */
-DSQLITE_THREADSAFE=0
-DSQLITE_OMIT_LOAD_EXTENSION
-DSQLITE_OMIT_DEPRECATED
-DSQLITE_DEFAULT_PAGE_SIZE=1024
-DSQLITE_MAX_EXPR_DEPTH=0
-DSQLITE_OMIT_SHARED_CACHE
-DSQLITE_LIKE_DOESNT_MATCH_BLOBS
-DSQLITE_DEFAULT_CACHE_SIZE=32
/* 交叉编译 */
arm-linux-gnueabi-gcc -Os sqlite3.c shell.c -o sqlite3 ${CFLAGS}
经过激进裁剪并用-Os优化后，SQLite核心库可以压缩到300KB以内，只保留基本SQL功能甚至能到200KB左右。还要提醒一点：嵌入式平台务必用-Os而非-O2，并考虑去掉shell命令行工具，它能省下可观的代码空间。数据库文件本身的体积则取决于页大小设置，在1KB页大小下存储小记录，文件膨胀会明显小于4096页大小，但大记录场景则相反，需要实测决定。
三、Flash写入量与运行性能优化
嵌入式设备普遍使用NAND Flash或eMMC，它们都有有限的擦写次数，因此SQLite对Flash的写入模式值得关注。默认的回滚日志模式下，每次事务提交需要写日志页、写数据页、再删除日志，一次小更新可能放大成数倍的物理写入。切换到WAL模式后，写操作只追加到WAL文件，随机写变成顺序写，对Flash友好得多，但需要权衡checkpoint时机。
除了日志模式，还有几个实践技巧能显著降低写入放大。第一，合理合并事务，把多条小更新放进一个事务里提交，避免每条记录一次fsync；第二，将WAL文件和数据文件放在RAM文件系统或单独分区，减少对主存储的磨损；第三，对频繁更新的计数字段考虑放在内存中，定期批量落盘；第四，索引不要建得过多，每个索引都会增加写入路径上的页修改量。同时建议开启PRAGMA synchronous = NORMAL，在掉电风险可控的设备上这是安全性与寿命的最佳平衡点。
-- 嵌入式设备推荐的持久化配置 PRAGMA journal_mode = WAL; PRAGMA synchronous = NORMAL; PRAGMA wal_autocheckpoint = 256; -- 控制checkpoint频率 PRAGMA cache_size = -64; -- 负值表示64KB缓存 PRAGMA temp_store = MEMORY; -- 临时表放内存，避免写Flash
在CPU方面，SQLite的解析和执行效率对大多数嵌入式应用绰绰有余，真正的瓶颈通常在存储I/O。如果你的数据访问模式非常简单，比如只有按主键查询，可以考虑用WITHOUT ROWID表结构，让数据按主键聚簇存储，减少一次B树查找。查询时避免SELECT *，只取需要的列，也能减少页加载和内存拷贝。
四、选型判断与替代方案
综合来看，SQLite适合RAM在256KB以上、Flash在1MB以上、且有结构化查询需求的嵌入式设备。它的优势是事务安全、SQL表达能力完整、生态成熟；代价是内存下限比专用格式高一个数量级。
如果设备资源更紧张，可以按需求降级选型：只需键值存取时LevelDB的裁剪版或自研哈希索引文件更省；只需要追加日志时直接写顺序文件即可；需要复杂查询但无法承担SQLite开销时，可以考虑将数据上报到网关侧处理。在之间地带，还有SQLite的绝对模式（SQLITE_CONFIG_SINGLEPROCESS）以及一些商业嵌入式数据库可供选择。无论选哪条路线，建议先在实际硬件上跑一轮基准测试，用sqlite3_memory_used()接口监控真实内存曲线，再做最终决定，这比任何纸面数据都可靠。