【存储工程】LMDB 与内存映射存储
内容提要
本文探讨内存映射I/O（mmap）在数据库存储引擎中的应用，重点分析LMDB架构：通过mmap实现零拷贝读取，采用写时复制B+Tree和双元数据页保证事务与崩溃安全，无需WAL和Buffer Pool。文章对比BoltDB和BadgerDB，指出mmap存在TLB压力、页缺失延迟不可预测、I/O错误难处理等局限，适合读密集、中小规模场景，写密集或大库则需考虑Buffer Pool方案。
延伸解读
mmap 的适用边界
mmap 并非万能，其优势在热数据、读密集场景下明显，但大库随机访问时 TLB 压力和页缺失延迟不可忽视。文章引用 CIDR 2022 论文指出，当数据库超过几 GB 时，mmap 随机读延迟可能比 Buffer Pool 方案高 10-30%。因此，mmap 更适合中小规模、读多写少的嵌入式场景，而写密集或大库则需考虑 Buffer Pool 方案。
LMDB 的崩溃安全机制
LMDB 通过双元数据页和写时复制 B+Tree 实现崩溃安全，无需 WAL。提交时先刷数据页，再刷元数据页，利用扇区原子写保证一致性。这种设计简化了恢复逻辑，但代价是每次提交需两次 fdatasync，写放大与树深度相关。理解这一机制有助于评估其在断电场景下的可靠性，以及为何不适合高并发写。
写放大与性能权衡
CoW B+Tree 的写放大与树深度成正比，修改一个键需复制从叶子到根的路径。例如 10GB 数据、深度 5 时，单次写入约 28KB。相比 WAL 的顺序追加，CoW 随机写性能较差。因此，LMDB 适合批量写事务以分摊 fsync 开销，而 BadgerDB 等 LSM 引擎通过值分离降低写放大，更适合写密集场景。
读事务的运维陷阱
长时间运行的读事务会阻止空闲页回收，导致数据库文件持续膨胀。这是 LMDB 使用中最常见的陷阱之一。建议将读事务控制在毫秒级，避免在事务中执行耗时操作。同时，监控数据库文件增长，若文件增大但数据量未增，需检查是否有长事务未关闭。
Q&A
LMDB 如何实现零拷贝读取？
LMDB 通过 mmap 将整个数据库文件映射到进程地址空间，读取时直接通过指针访问 Page Cache 中的数据，无需系统调用和内存拷贝，从而实现零拷贝读取。
LMDB 为什么不需要 WAL？
LMDB 采用写时复制（CoW）B+Tree 和双元数据页设计，写事务只追加新页，不修改旧页，提交时原子切换元数据页，保证磁盘上始终有一致的数据状态，因此无需 WAL。
mmap 存储引擎有哪些主要缺点？
mmap 存储引擎的主要缺点包括：TLB 压力大（大数据库时随机读性能下降）、页缺失延迟不可预测、I/O 错误难以处理（SIGBUS）、无法精确控制回写时机、不支持异步 I/O。
LMDB 与 BoltDB 在写入方式上有何不同？
LMDB 使用 pwrite() 系统调用追加新页，然后 fdatasync() 刷盘；BoltDB 则直接通过 mmap 映射区域写入脏页，然后 fdatasync()。两者都采用 CoW B+Tree，但写入路径不同。
BadgerDB 如何降低写放大？
BadgerDB 采用键值分离（WiscKey 思想），将键和值指针存储在 LSM-Tree 中，值单独存储在值日志（vLog）中，压缩时只搬运键和指针，值只写一次，从而显著降低写放大。
LMDB 适合哪些场景？
LMDB 适合读密集型嵌入式数据库、中小规模数据（几百 MB 到几 GB）、需要多进程共享、极简部署和强一致性保证的场景。
长时间运行的读事务对 LMDB 有什么影响？
长时间运行的读事务会阻止空闲页回收，因为旧页可能仍被读事务引用，导致数据库文件持续增长，这是 LMDB 使用中的常见陷阱。
mmap 与 pread + Buffer Pool 相比，在读取性能上有何差异？
在热数据（数据在 Page Cache）场景下，mmap 通常优于 pread，因为省去了系统调用和内存拷贝；但在冷数据或大数据库场景下，mmap 的 TLB 压力和页缺失延迟会导致性能下降，Buffer Pool 方案可能更优。
