OLTP（联机事务处理，典型如银行交易、订单系统、用户增删改查）之所以普遍使用 B+ 树 作为索引结构，核心原因是：B+ 树非常契合 OLTP 的访问模式——大量随机读写、高并发、点查与范围查并存、要求稳定低延迟。
下面从几个关键角度说明。
OLTP 通常具有：
B+ 树在这些场景下表现非常均衡。
B+ 树是 多路平衡树：
相比二叉搜索树（如 AVL、红黑树）：
✅ B+ 树显著减少随机 IO
B+ 树特点：
好处：
B+ 树的叶子节点通过 双向链表相连：
[10,20] -> [21,30] -> [31,40]
因此：
OLTP 常见：
✅ B+ 树对范围查询极友好
B+ 树：
对比：
✅ B+ 树在“读多写多”下仍稳定
数据库通常：
因为：
这是 InnoDB 等存储引擎的标准组合。
| 结构 | 问题 |
|---|---|
| 哈希索引 | 不支持范围查询，冲突处理复杂 |
| 红黑树 / AVL | 树太高，磁盘 IO 多 |
| 堆文件 | 无索引，查询慢 |
| LSM 树 | 读放大明显，适合写多读少（OLAP/日志） |
LSM 树（如 RocksDB）更适合 写极端多、读较少 的场景，不是典型 OLTP 首选。
OLTP 用 B+ 树，是因为它能在磁盘存储、高并发、点查+范围查、频繁写入之间取得最佳平衡。
如果你愿意，我也可以对比：
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
