B+ 树适合什么场景，还有哪些索引实现方案？

B+ 树适合既要按键定位，又要按键的顺序进行范围查找、排序遍历的场景，尤其常见于按页组织、需要持久化的大数据集。 关系数据库中的普通索引是典型用途。

它的内部节点主要存导航键和子节点引用，一个页可以容纳较多分支，让搜索路径通常较短；叶子保存索引条目，并通过相邻链接支持有序遍历。点查可以沿树定位，范围查找则先找到起点，再沿叶子继续扫描，不需要为每个后续键重新从根查起。

其他方案要按需求选：Hash 更适合等值定位，LSM 更侧重批量组织写入与后台合并，倒排索引适合按词项找到匹配文档。 没有一种结构在所有工作负载下都最好。

数据库读写通常以页为单位，索引不能只比较内存中一次比较的复杂度。相较于二叉树，B+ 树每个内部页可以导航到更多子页，同样规模下通常需要经过更少层级。

不过，树高不等于每次查询实际发生的磁盘 I/O 次数：根页、内部页或叶子页可能已在缓存中，回表、预读和结果规模也会影响成本。叶子有序相邻也不等于物理文件中必然连续存放。

以 InnoDB 为例，聚簇索引的叶子保存行记录，二级索引的叶子保存二级键和主键等信息；未覆盖的查询还可能需要回表。因此“用了 B+ 树索引”不代表一定快。范围很大、回表很多或要跳过大量深分页记录时，仍可能开销很高。

写入也不是免费的：维护有序页可能涉及页分裂、合并和日志等成本。索引越多、键越宽，通常越需要关注写入与存储代价。

Hash 索引：通过哈希值定位桶，再判断键是否匹配，适合大量等值查询。它不保留键的顺序，不能仅靠这套结构高效完成“价格从低到高”或“某个时间区间”的遍历；还要处理冲突、容量与空间开销。不能把平均查找较快理解成任何场景都比 B+ 树快。
B 树、平衡二叉树等有序结构：同样可以支持有序访问。B 树可以在内部节点保存记录或记录引用，B+ 树则把相应数据条目集中在叶子，便于统一的叶子扫描。平衡二叉树适合不少内存有序集合，不能只因为高度更大就说它没有用途；是否合适取决于内存布局、页结构和负载。
LSM 类存储组织：以 RocksDB 为例，写入先缓冲到内存，并可通过 WAL 记录，再刷成有序 SST 文件，后台持续合并。它把较多写入组织为批量输出，但需要承担合并引起的写放大、多个数据来源的读取与空间取舍，合并跟不上时还可能阻塞写入。LSM 也支持范围扫描，只是需要合并多个有序来源，不能说它只能点查或写入必然更快。
倒排索引：组织“词项→包含该词项的文档列表”，例如搜索“蓝牙耳机”时先取得相关词项的候选，再进行交并、过滤和排序。适合全文检索或按标签找对象；分词、词项匹配和相关性语义，与数值区间、原字符串完全相等并不是同一问题。

这些概念不完全在同一层：LSM 涉及整体存储组织，倒排描述词项到文档的映射，内部还可以使用哈希、有序结构等。不能认为选了倒排就一定排除了树结构，也不能据此认为 InnoDB 普通索引可以直接配置成 RocksDB 的 LSM。

查某用户最近一段时间的订单，并按创建时间返回，可以优先考虑与过滤、排序匹配的 B+ 树联合索引；它能否减少扫描，还要看索引列顺序、查询条件与需要返回的字段。

按商品描述搜索“降噪耳机”，则更适合评估倒排检索；大规模键值写入场景可以进一步评估 LSM 引擎的读写比例、合并资源和延迟要求。它们是参考选型场景，最终仍应结合真实数据分布和执行结果验证。

电商问数第 5 章：Qdrant 与 ES 快速入门与接入：§2.4 用 text 与 keyword 的差异说明分词检索和整体值匹配，适合对照理解“按什么方式访问数据”为什么决定索引设计；本题另外展开 B+ 树、Hash 与 LSM 的取舍。

国内：JavaGuide：MySQL 索引详解：采用 B+ 树、聚簇/二级索引与覆盖索引部分，说明树结构怎样服务点查与范围访问，以及二级索引为什么可能额外回表。
国内：小林coding：为什么 MySQL 采用 B+ 树作为索引：采用内部节点分支与叶子范围遍历的解释，说明 B+ 树适合页式存储的原因，并用时间区间访问理解其有序性。
国内：美团技术团队：广告实时索引的设计与实现：采用词项、文档列表与布尔检索部分，解释倒排索引解决的访问需求，以及倒排映射内部也能组合哈希等结构。
国外：MySQL 8.4：Comparison of B-Tree and Hash Indexes：采用等值、范围、排序和完整键匹配的比较，说明有序索引与 Hash 索引在查询能力上的差别。
国外：RocksDB：RocksDB Overview：采用 Memtable、SST、迭代器和 Compaction 部分，解释 LSM 的写入组织、范围扫描能力，以及合并对读写和空间的影响。