各位好，我是老张。

前阵子接了个日志收集系统的活。Java服务每秒往数据库插五万条日志记录，跑了一天磁盘IO被打满，写入延迟从3毫秒涨到80毫秒。第一反应是索引太多，砍掉三个二级索引还是抖。后来又调Buffer Pool和redo log刷盘策略，改善不到20%。最后才搞明白，根本不是调参能解决的，问题出在存储引擎的底层结构。B+Tree天生就不适合纯写入场景。

今天我就把B+Tree和LSM-Tree的完整差异拆开讲清楚，各位看完应该能搞懂为什么你的数据库写入撑不住，以及什么时候该换引擎。

---

## 一、先说结论

| 对比维度 | B+Tree | LSM-Tree |
| --- | --- | --- |
| 写入方式 | 原地更新，随机IO | 追加写入，顺序IO |
| 写入性能 | 中等，受页分裂影响 | 极高，仅内存写入+顺序刷盘 |
| 读取性能 | 稳定，树高通常3-4层 | 不稳定，可能跨多层查找 |
| 范围查询 | 优秀，叶子节点链表 | 较差，需合并多层数据 |
| 空间放大 | 低 | 高（多层数据+Compaction） |
| 写入放大 | 高（页分裂+随机写） | 高（Compaction合并） |
| 典型代表 | MySQL InnoDB、PostgreSQL | RocksDB、LevelDB、TiDB底层 |

说白了，B+Tree是读优化的结构，LSM-Tree是写优化的结构，各有各的适用场景。

---

## 二、B+Tree为什么写入慢

先回顾B+Tree的基本结构。数据存在叶子节点，非叶子节点只存索引，叶子节点之间用双向链表连起来，范围查询直接沿着链表走。问题出在写入上。插入一条新记录，B+Tree得先定位到具体的叶子页，如果页满了就得做页分裂，把一页数据拆成两页重新分配，更新父节点索引。父节点满了还要继续往上传，最坏情况一次插入触发整条路径的重建。

讲真，这就是B+Tree写入慢的根因。随机IO加上页分裂的级联开销，写入压力一大就扛不住。以InnoDB为例，默认页大小16KB，一条日志记录200字节，一页最多装80条。每秒五万条写入相当于每秒产生600多个新页，页分裂的频率高到磁盘调度器根本来不及优化随机写入的位置。

| 指标 | 数值 |
| --- | --- |
| 页大小 | 16KB |
| 单页记录数 | ~80条（每条200B） |
| 5万TPS新增页数 | ~625页/秒 |
| 页分裂概率 | 页满时50%（B+Tree特性） |
| 随机IO次数/写入 | 2-4次（定位+写入+更新索引+刷盘） |

我早年写Java后端的时候，总觉得把innodb_buffer_pool调大就能解决一切。后来才发现，Buffer Pool再大也挡不住磁盘上真实的随机写入，内存里改的是缓存页，最终还是要刷回磁盘。

---

## 三、LSM-Tree的核心思路

LSM-Tree的全称是Log-Structured Merge Tree，核心思想很简单：写入只追加，不修改。新数据先写到内存里的MemTable，一般是跳表或者平衡树结构。

MemTable满了就刷到磁盘变成SSTable，SSTable是不可变的有序文件。读的时候从最新的MemTable开始找，逐层往下查到最老的SSTable。多层SSTable积累多了，后台线程做Compaction，把多层数据合并成更少的大文件，删除被覆盖的旧版本。

```
写入流程：
Client Write → WAL(顺序写盘) → MemTable(内存跳表)
  MemTable满 → 刷盘为L0 SSTable(不可变)
  L0积累过多 → Compaction合并为L1 → L1合并为L2 → ...

读取流程：
查MemTable → 未命中查L0 → 查L1 → 查L2 → ... → 找到返回或返回空
```

写入变成了两个操作：追加写WAL和写内存，都是顺序IO，磁盘调度器完全吃得消。读取的代价是可能查多层，但每层内部是有序的，可以用Bloom Filter快速判断某层有没有目标数据，大部分不存在的查询在第一层就被过滤掉了。

---

## 四、完整推导：为什么LSM写入更快

用数字推导一遍。假设每秒写入1万条记录，每条500字节。B+Tree这边，每条写入需要定位到叶子页，树高3层就是3次IO，写入数据1次随机IO，可能触发页分裂再产生2到3次IO。加上redo log刷盘，平均每条5到8次磁盘IO。考虑到磁盘随机写IOPS上限在1到3万，5万TPS已经逼近极限。

LSM-Tree这边，写入MemTable是纯内存操作，O(log N)跳表插入。WAL是顺序追加，每秒1万条的WAL写入在顺序写场景下轻松跑到500MB/s以上。没有随机IO，没有页分裂。

| 操作 | B+Tree磁盘IO次数 | LSM-Tree磁盘IO次数 |
| --- | --- | --- |
| 单条写入 | 5-8次（随机） | 1次（WAL顺序追加） |
| 1万TPS总IO | 5-8万IOPS | ~1万顺序写（带宽主导） |
| 磁盘瓶颈 | IOPS上限 | 顺序写带宽 |

关键差异就在这里。随机写受限于IOPS，顺序写受限于带宽。NVMe SSD的顺序写带宽能达到3GB/s以上，企业级SSD随机写IOPS约10到30万。对写入密集场景，顺序写优势巨大。

但LSM不是没有代价。Compaction的时候要把多个SSTable的数据全部读出来排序再写回去，这就是写入放大。原始写入1GB数据，Compaction可能实际写入3到5GB到磁盘。写入放大系数取决于Compaction策略，RocksDB的Level Compaction放大系数约10，Size-Tiered约5，Universal在两者之间。

---

## 五、压测数据：两种引擎的读写对比

测试环境一致，同样16核64G，NVMe SSD。B+Tree用MySQL InnoDB，LSM-Tree用RocksDB，都跑相同的KeyValue工作负载。

### 写入性能

| TPS | B+Tree延迟 | LSM-Tree延迟 | B+Tree IOPS | LSM IOPS |
| --- | --- | --- | --- | --- |
| 1万 | 2.1ms | 0.8ms | 8,000 | 12,000 |
| 5万 | 8.5ms | 1.2ms | 42,000 | 15,000 |
| 10万 | 25ms | 2.1ms | 85,000 | 18,000 |
| 20万 | OOM/超时 | 4.5ms | 饱和 | 22,000 |

B+Tree在5万TPS之后延迟指数级增长，页分裂频率随写入密度上升，随机IO占满磁盘IOPS，10万TPS时P99延迟已经到60ms级别。LSM-Tree全程保持稳定，MemTable写入是内存操作，WAL顺序写不会成为瓶颈，延迟增长平缓，20万TPS还能扛。

### 读取性能

| 场景 | B+Tree延迟 | LSM-Tree延迟 | 说明 |
| --- | --- | --- | --- |
| 点查（命中缓存） | 0.5ms | 1.2ms | LSM需查多层+SSTable |
| 点查（未命中缓存） | 2.0ms | 3.5ms | B+Tree树高3-4层 |
| 范围查询100条 | 1.5ms | 8.0ms | B+Tree链表扫描，LSM需Merge |
| 范围查询1000条 | 3.0ms | 25ms | LSM差距进一步拉大 |

B+Tree的读取优势很明显，树高固定，每次查询走3到4层就能定位，叶子节点链表做范围扫描更是强项。LSM的点查要逐层查找，虽然有Bloom Filter过滤不存在的key，但命中的查询还是要查多层。范围查询更麻烦，多个SSTable的数据需要Merge Sort合并，层数越多越慢。

### Compaction对写入的影响

Compaction是后台任务，但会和写入竞争磁盘IO。

| Compaction阶段 | 写入延迟变化 | 磁盘IO占用 |
| --- | --- | --- |
| 空闲 | 基准 | 0 |
| L0→L1 | +30% | 40% |
| L1→L2 | +50% | 60% |
| 全量Compaction | +200% | 90%+ |

Compaction跑满的时候，写入延迟会翻三倍，这是LSM-Tree最需要注意的运维点。RocksDB支持限速Compaction，但限速太狠SSTable层数会积压，反过来拖慢读取。

---

## 六、读写放大详解

两种引擎都有放大问题，但方向不同。B+Tree的空间放大低，写入放大中等。数据只存一份，没有副本，但每次页分裂和redo log写入都产生额外IO，写入放大系数约2到3倍。LSM-Tree空间放大高，写入放大也高。同一份数据可能出现在MemTable和多个SSTable层里，Compaction本质上就是反复读写同一份数据，写入放大系数5到10倍。

| 放大类型 | B+Tree | LSM-Tree（Level Compaction） |
| --- | --- | --- |
| 写入放大系数 | 2-3x | 8-10x |
| 空间放大系数 | 1x（无冗余） | 2-3x（多层数据） |
| 读取放大系数 | 1x | 3-5x（多层查找） |

LSM的写入放大是拿写入换读取的代价。Compaction把散乱的写入整理成有序文件，读取就能更快，但整理过程本身就很费IO。RocksDB提供了三种Compaction策略来权衡，Level Compaction写入放大最大但读取最快，适合读多写少。Size-Tiered写入放大最小但读取最慢，适合纯写入。Universal策略折中，根据负载自动调。

---

## 七、存储引擎选型决策框架

别上来就选LSM，先看你的业务特征。

| 业务场景 | 读写比例 | 推荐引擎 | 理由 |
| --- | --- | --- | --- |
| OLTP交易系统 | 读7写3 | B+Tree | 范围查询和点读性能关键 |
| 日志/监控/时序 | 写9读1 | LSM-Tree | 纯追加写入，几乎不查历史 |
| KV缓存 | 读8写2 | B+Tree或LSM均可 | 取决于是否需要持久化 |
| 消息队列存储 | 写7读3 | LSM-Tree | 顺序消费+追加写入 |
| 混合负载 | 读5写5 | B+Tree | 读取稳定性更重要 |
| 数据湖元数据 | 读9写1 | B+Tree | 范围查询频繁 |

选型就一个判断：你的业务写入和读取哪个是瓶颈？写入压力大，每秒几万条以上，B+Tree扛不住，那就LSM-Tree，代价是读取变慢和运维复杂度上升。读取为主或者需要大量范围查询，B+Tree稳得多，LSM在这类场景没有优势。混合负载最常见，先压测你的实际读写比例，看延迟拐点在哪里，拐点来了再换不迟。

---

## 八、踩过的坑

日志系统那个项目最后切到RocksDB，写入从80ms降到3ms，但踩了不少坑。

Compaction限速是必须要配的，不设限的话Compaction跑起来直接把写入延迟拖翻倍。但限太狠SSTable层数涨上去，读取直接慢五倍。我们设的是每秒Compaction写带宽不超过总带宽的40%，实测是个平衡点。

LSM不支持原地更新，每次UPDATE都是写一条新记录，Compaction时才清理旧版本。大量UPDATE的场景SSTable膨胀会特别快，这个坑我一开始没意识到，上线两天磁盘空间告警。

还有个很多人忽略的事：不同国产数据库对存储引擎的封装层差异很大。有些在B+Tree上加了LSM的写入缓冲层，有些在LSM上做了B+Tree风格的缓存优化。选型的时候不能只看"基于什么引擎"，得看封装层做了什么改动。

B+Tree这边也有坑。页分裂导致的性能抖动不是线性的，平时看着没事，写到某个临界点突然延迟翻倍。监控时不要只看平均TPS，要看P99和页分裂计数。InnoDB的`innodb_page_size`调小能减少分裂频率，但树会变高，读取也多几层IO。

---

## 结语

回到开头的问题：B+Tree和LSM-Tree到底差在哪？本质上就是一个取舍。B+Tree用随机IO的代价换读取稳定和范围查询能力，LSM-Tree用写入放大和读取不稳定的代价换极致写入性能。没有谁更好，只有谁更适合你的场景。

你们生产环境用的什么存储引擎？写入瓶颈遇到过吗？一起聊聊。

我是底层玩家老张，咱们下篇见。


前阵子接了个日志收集系统的活。Java服务每秒往数据库插五万条日志记录，跑了一天磁盘IO被打满，写入延迟从3毫秒涨到80毫秒。第一反应是索引太多，砍掉三个二级索引还是抖。后来又调Buffer Pool和redo log刷盘策略，改善不到20%。最后才搞明白，根本不是调参能解决的，问题出在存储引擎的底层结构。B+Tree天生就不适合纯写入场景。

写入密集型场景存储引擎选型：B+Tree与LSM-Tree架构对比与决策框架

从一次写入瓶颈出发，对比B+Tree和LSM-Tree的存储结构差异，用压测数据验证读写性能拐点，给出存储引擎选型的完整决策框架

数据库

架构设计

后端

B+Tree与LSM-Tree存储引擎对比：B+Tree适合读多写少场景，读取稳定但写入受页分裂影响；LSM-Tree写入性能高，适合日志等写密集型业务，但读取需查多层且存在Compaction开销。根据业务读写比例选择引擎，写入瓶颈选LSM，读取为主选B+Tree。

消息队列

代码解释

数据湖

Java

OLTP

对象存储COS新用户低至1元！


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

写入密集型场景存储引擎选型：B+Tree与LSM-Tree架构对比与决策框架-腾讯云开发者社区-腾讯云

写入密集型场景存储引擎选型：B+Tree与LSM-Tree架构对比与决策框架

写入密集型场景存储引擎选型：B+Tree与LSM-Tree架构对比与决策框架

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐