一、LSM 核心原理（Log-Structured Merge-Tree）
1. 核心设计思想
- 写优先优化：通过「顺序写」替代「随机写」，规避磁盘随机 I/O 瓶颈（磁盘顺序写速度是随机写的 100+ 倍）。
- 分层存储 + 异步合并：数据按写入顺序分层存储，小批量写入内存，达到阈值后异步合并到磁盘，平衡读写性能。
- 不可变数据结构：磁盘上的数据文件（SSTable）一旦写入不修改，仅通过合并生成新文件，避免覆盖写的性能损耗。
2. 核心原理拆解（三层存储模型）
plaintext
内存层（MemTable） → 磁盘层（SSTable 分层） → 日志层（WAL）- WAL（Write-Ahead Log）：写入数据时先写日志文件（顺序写），防止内存数据丢失，是 LSM 可靠性的基础。
- MemTable：内存中的有序数据结构（通常是跳表 SkipList），接收实时写入，支持高效插入 / 查询（O (log n)）。
- SSTable（Sorted String Table）：磁盘上的有序 immutable 文件，当 MemTable 达到阈值（如 64MB），会异步 flush 到磁盘成为 L0 层 SSTable；后续通过「合并（Compaction）」操作，将低层 SSTable 合并为高层（L1、L2...），减少文件数量、优化查询效率。
3. 关键操作流程
| 操作 | 流程 |
|---|---|
| 写入（Put） | 1. 写 WAL（顺序写）→ 2. 写入 MemTable（内存有序插入）→ 3. MemTable 满则 flush 为 L0 SSTable |
| 查询（Get） | 1. 先查 MemTable → 2. 查 L0 SSTable → 3. 逐层查更高层 SSTable（直到找到数据或遍历完成） |
| 合并（Compaction） | 异步将多个低层 SSTable 合并为少量高层 SSTable，去重、排序，减少文件数和查询层数 |
二、LSM 的工程实现（核心组件 + 关键细节）
以 LevelDB/RocksDB（最经典的 LSM 实现）为例，拆解实现要点：
1. 核心组件
| 组件 | 实现细节 |
|---|---|
| MemTable | 基于跳表（SkipList）实现，保证插入 / 查询 O (log n)；支持快照（Snapshot），避免读阻塞写 |
| WAL | 二进制日志文件，按块（Block）顺序写入，每个日志条目包含 Key-Value、时间戳、删除标记（Tombstone） |
| SSTable | 1. 数据按 Key 有序排列；2. 分为数据块（Data Block）、索引块（Index Block）、元数据块（Meta Block）；3. 支持布隆过滤器（Bloom Filter），快速判断 Key 是否存在，减少无效磁盘 I/O |
| Compaction 策略 | 两种核心策略：- Leveled Compaction（LevelDB 用）：L0 与 L1 合并，L1 与 L2 合并... 逐层合并，控制每层文件大小；- Size-Tiered Compaction（HBase 用）：同层大小相近的文件合并，适合写入量大的场景 |
| 布隆过滤器 | 每个 SSTable 对应一个布隆过滤器，查询时先通过布隆过滤器判断 Key 是否在该文件中，过滤 99% 以上的无效查询 |
2. 关键优化（解决 LSM 固有问题）
- 读放大优化 ：
- 布隆过滤器（减少磁盘查询次数）；
- SSTable 索引块预加载（内存缓存索引，避免每次查询都读磁盘索引）；
- 合并时压缩数据（减少文件层数，降低查询时的文件遍历次数）。
- 写放大优化 ：
- 延迟合并（避免频繁合并）；
- 合并时批量处理（减少磁盘 I/O 次数）；
- 小文件合并阈值动态调整（根据写入压力自适应）。
- 空间放大优化 ：
- 合并时删除过期数据（Tombstone 标记的数据）；
- 数据压缩（Snappy/Zstd 压缩算法，减少磁盘占用）。
三、LSM 与 B+ 树的核心区别（从原理到工程落地）
1. 核心差异对比表（重点看「底层原理」和「工程适配场景」）
| 对比维度 | LSM（Log-Structured Merge-Tree） | B+ 树（B+ Tree） |
|---|---|---|
| 核心设计目标 | 优化写入性能（顺序写为主），牺牲部分读性能 | 优化查询性能（随机读为主），兼顾读写平衡 |
| 数据写入方式 | 顺序写（WAL + MemTable 顺序 flush），无随机写 | 随机写（需定位到叶子节点，覆盖写数据） |
| 数据存储结构 | 内存（MemTable）+ 磁盘分层（SSTable），不可变文件 | 磁盘上的树形结构（根节点、非叶子节点、叶子节点），数据可覆盖修改 |
| 读 / 写放大 | - 读放大：查询需逐层遍历 SSTable（可通过布隆过滤器优化）；- 写放大：Compaction 会重复写入数据（通常写放大 10-50 倍） | - 读放大：几乎无（通过索引直接定位叶子节点，一次磁盘 I/O 可读取多个数据）；- 写放大：较小（仅修改叶子节点和少量索引节点） |
| 适用场景 | 写密集型场景（如日志存储、时序数据、消息队列），例：TiDB、RocksDB、HBase | 读写均衡 / 读密集型场景（如关系型数据库、缓存），例：MySQL、PostgreSQL、Redis（跳表本质是简化版 B+ 树） |
| 事务支持 | 需额外实现（如 RocksDB 用 WriteBatch + 快照，TiDB 用 MVCC + 分布式事务） | 原生支持（通过锁机制 + 事务日志，如 MySQL 的 InnoDB 事务） |
| 空间占用 | 空间放大较高（存在大量过期数据，需等待 Compaction 清理） | 空间放大较低（数据直接覆盖，无冗余过期数据） |
2. 关键差异深度解读（开发者视角）
（1）写入性能：LSM 碾压 B+ 树
- LSM 写入是「顺序写」：无论数据量多大，写入都只是追加 WAL + 插入内存跳表，速度接近磁盘顺序写极限；
- B+ 树写入是「随机写」：每次写入需先通过索引定位到磁盘叶子节点，再覆盖写数据，磁盘随机写速度是顺序写的 1/100 左右，写密集场景下性能差距明显。
（2）查询性能：B+ 树更稳定
- B+ 树查询是「O (log n) 单次磁盘 I/O」：叶子节点有序且连续，通过索引直接定位，一次磁盘 I/O 可读取多个相邻数据（适合范围查询）；
- LSM 查询是「多层遍历」：需从 MemTable 到 L0、L1... 逐层查询，若布隆过滤器优化不到位，会产生多次磁盘 I/O，查询延迟波动较大（长尾延迟明显）。
（3）工程落地适配：场景决定选择
- 选 LSM：当业务是「写多查少」，且能接受轻微的读延迟波动（如日志采集、用户行为统计、时序数据存储）；
- 选 B+ 树：当业务是「读多写少」或「读写均衡」，且要求查询延迟稳定（如电商订单查询、用户信息查询、金融交易数据）。
四、总结（底层逻辑 + 应用选型）
1. 底层逻辑本质
- LSM：「用时间换空间 + 用顺序写换随机写」，通过异步合并牺牲部分读性能和空间效率，换取极致的写入性能；
- B+ 树：「用空间换时间」，通过树形索引和有序叶子节点，保证稳定的查询性能，兼顾写入（但写入性能受限）。
2. 开发者选型建议
- 若用 Java 生态：
- 写密集场景：可基于 RocksDB 封装（如 TiDB 的存储层），或用 HBase（基于 LSM 实现）；
- 读密集 / 事务场景：用 MySQL InnoDB（B+ 树），或 PostgreSQL。
- 若用 Go/Python 生态：
- 轻量级写密集场景：直接用 RocksDB 的绑定库（如 Go-RocksDB）；
- 复杂查询场景：用 PostgreSQL（B+ 树）或 TiDB（LSM 底层 + SQL 层优化）。
- 核心判断标准：
- 写入 QPS 是否远高于查询 QPS？→ 选 LSM；
- 是否要求查询延迟稳定（P99 低）？→ 选 B+ 树；
- 是否需要支持复杂事务？→ 优先 B+ 树（LSM 需额外封装）。
TIDB等newsql这使用LSM，关系型数据库首选B+