SQLite和Berkeley DB都属于嵌入式数据库领域的经典实现，但它们的设计哲学从一开始就走向了两个方向。SQLite把关系数据库的方便性带进进程内，强调零配置、单文件、SQL兼容；Berkeley DB则更像一个可编程的数据存储库，提供多种底层数据结构，把索引、缓存、事务等细节交给调用者控制。理解这些差异需要从存储组织、事务日志、并发控制以及实际开发中的API形态展开。
存储模型与数据组织方式
SQLite的存储模型建立在一个或多个B树页面上，每个数据库文件由固定大小的页组成，页大小通常可以在创建时指定，常见值为4096字节。所有表、索引都存储在同一个文件中，采用变长记录和动态类型。SQLite的数据类型亲和性让同一列可以混合存储整数、浮点、文本甚至BLOB，这在原型开发阶段非常灵活。但这也意味着查询执行时需要额外的类型转换和判断，对CPU缓存不够友好。SQLite的B树由SQL层直接管理，用户无法绕过SQL去修改底层页面，这种封装降低了误操作风险，也限制了自定义存储布局的可能。
Berkeley DB的存储模型要更加多样化，它提供B树、哈希、队列和递归编号记录四种访问方式。开发者可以为一个环境创建多个数据库文件，每个文件可以选用不同的访问方式，也可以自定义键值比较函数、哈希函数和数据压缩逻辑。Berkeley DB没有SQL层，数据以原始字节串形式存入，键和值都没有固定模式，这在序列化协议、日志存储和缓存系统里很有优势。因为没有关系模型的约束，写入路径更短，不需要解析SQL、生成查询计划、执行约束检查。代价是开发者必须自己处理数据编码、版本演进和查询逻辑。对于需要二级索引的场景，Berkeley DB要求开发者额外维护索引数据库，而SQLite可以通过CREATE INDEX语句自动维护。
从文件布局看，SQLite单文件特性方便备份和分发，但活跃并发写入时所有页面竞争同一个文件锁；Berkeley DB允许一个环境包含多个文件和日志目录，配合多版本并发控制可以把不同索引或表的竞争分散开。测试中如果需要频繁重建表结构，SQLite的ALTER TABLE操作通常会触发整表数据迁移，而Berkeley DB因为键值存储，只需要改变应用层序列化格式，底层文件结构不变。当然这也把版本兼容压力转移到应用代码上。
事务日志与崩溃恢复机制
事务持久性是嵌入式数据库能否用于工业环境的关键指标。SQLite默认采用回滚日志模式，在修改数据库页之前，先把原始页写入一个单独的日志文件。事务提交时日志文件被同步到磁盘，然后把修改后的页写回主数据库文件，最后删除或截断日志。这种策略保证了任何时候发生崩溃，要么恢复旧状态，要么完成提交。回滚日志模式的问题在于写入放大，同一个页面在事务期间可能被写多次。SQLite也提供了WAL模式，即写前日志，它把修改追加到独立的WAL文件，允许读者和写者并发工作，提交时只需同步WAL，主数据库文件的写入可以延迟。WAL模式显著提升了并发读写吞吐，但要求所有访问同一数据库的进程共享内存，不适合网络文件系统。
Berkeley DB的事务模型基于更传统的日志先行协议。它维护单独的日志区域，事务提交时强制把日志记录写入磁盘，数据页则由缓存管理器在检查点或内存压力时刷回。Berkeley DB允许配置日志缓冲区大小、检查点间隔和事务提交同步级别。例如DB_TXN_NOSYNC可以在极端性能要求下关闭同步写日志，但会丢失最后一次提交的持久性。这种粒度控制在SQLite里对应PRAGMA synchronous参数，但Berkeley DB的选项更底层，支持不同事务实例使用不同持久化策略。同时Berkeley DB的恢复过程会扫描日志、重做已提交事务、撤销未提交事务，适合长时间运行的应用。
两者在恢复细节上还有一点重要区别：SQLite的日志文件和主数据库文件紧密绑定，移动或复制数据库时必须考虑日志状态，否则可能读到旧数据或损坏；Berkeley DB的环境由多个文件和日志组成，备份时需要配合db_hotbackup等工具做一致性快照，单独复制数据文件并不安全。对于嵌入式设备掉电场景，建议SQLite开启fullfsync并定期执行PRAGMA wal_checkpoint，Berkeley DB则配置合理的log缓冲区并定期txn_checkpoint，避免日志文件无限增长。
并发控制与锁粒度
SQLite的并发控制经历了从数据库级锁到WAL读写分离的演进。在回滚日志模式下，同一时间只允许一个写者，写事务会阻塞所有读者，这是简单的文件锁加共享缓存实现。WAL模式下写者不再阻塞读者，但多个写者仍然串行，因为SQLite只有一个写队列。这种设计对于绝大多数移动端、桌面端单进程或低并发场景足够，但如果多个进程高频写入同一个库，锁竞争会迅速成为瓶颈。SQLite也提供busy_timeout和BEGIN IMMEDIATE等机制缓解写冲突，但无法实现真正的多写者并行。
Berkeley DB的并发控制则灵活得多。它支持页级锁，配合事务隔离级别，多个写事务可以同时修改不同的数据页。默认隔离级别是可重复读，锁管理器会跟踪读写锁，死锁检测器自动回滚其中一个事务。Berkeley DB还提供DB_TXN_SNAPSHOT隔离级别，基于多版本并发控制实现接近无阻塞的读写。因为锁粒度更细，在高并发、写密集负载下Berkeley DB通常能获得更好吞吐。不过页级锁也会带来锁管理开销，如果访问模式高度集中，多个事务竞争同一页面时性能可能反而下降。开发者需要通过合理的键分布和数据分片来充分利用并发能力。
另一个容易被忽略的差异是跨进程协调。SQLite依赖操作系统文件锁，NFS等网络文件系统上行为不稳定；Berkeley DB支持共享内存和POSIX信号量，在本地多进程环境中更加可靠。对于嵌入式系统里常见的单进程多线程模型，SQLite的共享缓存模式需要谨慎使用，历史上出现过连接之间锁升级的问题；Berkeley DB在多线程使用时需要为环境指定DB_THREAD标志，并注意某些句柄不能跨线程共享。总体来说，如果应用以读为主、写操作稀疏，SQLite的简单性胜出；如果存在多个写入者或长时间事务，Berkeley DB的锁机制更具备扩展性。
API形态与选型建议
从开发体验看，SQLite提供的是标准SQL接口，几乎所有语言都有成熟的绑定。C语言中通过sqlite3_prepare_v2、sqlite3_step处理查询，Java、Python、Go等语言则封装成ORM或驱动，学习成本低。以下是一个简单的C语言插入示例：
#include <sqlite3.h>
#include <stdio.h>
int main(void) {
sqlite3 *db;
sqlite3_open("test.db", &db);
sqlite3_exec(db,
"CREATE TABLE IF NOT EXISTS kv(k TEXT PRIMARY KEY, v TEXT);",
NULL, NULL, NULL);
sqlite3_exec(db,
"INSERT INTO kv(k, v) VALUES('name', 'embedded');",
NULL, NULL, NULL);
sqlite3_close(db);
return 0;
}可以看到，SQLite把SQL语句作为字符串传递，运行时解析执行。这种方式便于动态拼接和调试，但每次调用都有解析开销，参数绑定可以缓解这个问题。
Berkeley DB的API则围绕数据库句柄和事务对象展开，C语言中需要调用db_create、db->open、db->put等方法。典型的存储操作如下：
#include <db.h>
#include <string.h>
int main(void) {
DB *dbp;
DBT key, data;
int ret;
db_create(&dbp, NULL, 0);
dbp->open(dbp, NULL, "access.db", NULL, DB_BTREE, DB_CREATE, 0);
memset(&key, 0, sizeof(key));
memset(&data, 0, sizeof(data));
key.data = "name";
key.size = 5;
data.data = "berkeley";
data.size = 9;
ret = dbp->put(dbp, NULL, &key, &data, 0);
dbp->close(dbp, 0);
return ret;
}Berkeley DB代码中所有数据结构都需要手动填充，键和值以DBT结构表达，实际数据仍然由调用者管理。这种方式没有SQL解析，写入路径更直接，适合高频写入或二进制数据。但错误处理、游标管理、事务嵌套等都需要更细致的代码，开发成本明显更高。
选型上可以简单归纳：如果应用需要关系查询、报表生成、多表连接，或者希望数据文件可以直接用SQL工具查看，SQLite是更合适的选择；如果应用是网络代理、缓存服务、文件索引、消息队列等以键值访问为主的组件，或者对写入延迟和并发吞吐有苛刻要求，Berkeley DB更值得评估。还有一种折中方案是在Berkeley DB之上实现SQL引擎，例如早期MySQL的存储引擎层就曾支持Berkeley DB，但维护成本很高，一般仅在特定历史项目中出现。现代新项目更倾向于用SQLite应对关系需求，用LSM树类引擎如LevelDB或RocksDB应对高写入场景，而Berkeley DB在需要细粒度事务和成熟恢复机制的嵌入式场景中仍有独特价值。
无论选择哪一种，都应基于真实负载做基准测试。SQLite可以通过PRAGMA journal_mode=WAL和PRAGMA synchronous=NORMAL调节性能与安全性；Berkeley DB则需要关注缓存大小、日志目录和检查点策略。两者的性能并不存在绝对的优劣，只有与访问模式、部署环境、开发团队熟悉度匹配时才能发挥最佳效果。
SQLiteBerkeley DB嵌入式数据库修改时间：2026-08-21 23:25:57