B+树为何是数据库默认索引？哈希索引和B+树索引选型实战

1. 从一次“速度打脸”说起：等值查询明明哈希快，为何默认索引还是B+树

很多人第一次接触哈希索引和B+树索引的对比，第一反应都是：这有什么好争的？哈希索引等值查询O(1)，B+树索引要老老实实走树路径O(log n)，高下立判。我早年做登录模块优化时也这么想过——用户表几千万行，每次登录都要用手机号等值查用户，这不就是哈希索引的主场吗？于是我专门建了一张哈希索引测试表，单条等值查询压测下来确实快得离谱，有时比同条件下的B+树索引快一个量级。

但是只要把这个测试放到完整业务里，立刻露馅。一个用户登录进来，不只是查他那一条记录，还要查他的订单列表、优惠券记录、操作日志，这些查询要么带时间范围、要么带排序、要么要按多个字段联合筛选。哈希索引面对这些场景，基本帮不上忙。而B+树索引虽然单点查询慢一截，却能把范围查询、排序、分组、覆盖索引全都包揽下来。数据库默认选择B+树作为主流索引结构，根本不是因为它单点最快，而是因为它更适合真实业务里那种混合查询负载。

这篇文章不打算只停留在“哈希无序、B+树有序”这种一句话结论上，而是把哈希索引和B+树索引的底层存储、磁盘IO特征、并发行为、实际选型条件都拉出来过一遍，最后再分享几个我在生产环境里踩过的索引坑。无论你是刚入门数据库的开发者，还是维护线上库的DBA，应该都能从这里找到一些能直接用的判断思路。

顺便提一嘴，最近不少朋友在聊“索引存储和哈希存储”“数据库开启审计引起索引争用”这些话题，这几个点其实都指向同一个问题：索引结构的选择不是拍脑袋，而是由访问模式、存储介质和并发模型共同决定的。 下面我们就一层一层拆开看。

2. 数据结构底牌：哈希表和B+树分别是怎么把数据“放”下来的

要搞清楚为什么B+树能坐稳数据库索引王者的位置，首先得看两种结构在磁盘上到底长什么样。很多人以为索引就是一张加速查找的表，这个理解方向没错，但漏掉了最关键的物理约束——数据是放在磁盘上的，磁盘读写的最小单位是页，不是单条记录。

2.1 哈希索引的存储结构：快，但快得很“局部”

哈希索引的本质是一张哈希表。写入时，索引键经过哈希函数计算，得到一段固定长度的散列值，这个值决定了记录应该落在哪个桶里；查询时也走同样的哈希计算，一步定位到桶，再在桶内部的链表或者溢出页里找到对应记录。

听起来很完美，对吧？问题在于，哈希表天生不维护键的顺序。你只关心“手机号138****等于某个值”时，哈希索引确实是神器；可一旦查询变成“注册时间在2024年1月到3月之间”，哈希索引就完全抓瞎了，因为它根本不知道“相邻的键”被散列到了哪个桶里。极端情况下，两个时间上连续的注册记录，哈希值可能一个落在桶1、一个落在桶100000，这种物理分布上的随机性，决定了范围查询只能全量扫描后再过滤。

另一个容易被忽略的问题是哈希冲突。哈希函数设计得再好，数据量一大，不同键落到同一桶的概率就会上升。冲突多了，一个桶里的链表越来越长，哈希索引的O(1)复杂度就会退化成O(n)，和全表扫描没本质区别。数据库里的哈希索引一般会用动态哈希、可扩展哈希这些手段来降低冲突，但复杂度也随之上升，维护成本不再是“算一下就行”。

2.2 B+树的存储结构：每一层都在为“磁盘顺序读”服务

B+树是一种多路平衡查找树，它的节点大小通常和磁盘页对齐。InnoDB默认页大小是16KB，也就是说，B+树的一个节点，正好就是磁盘上的一页。读一个节点，本质上就是一次磁盘页IO。

B+树有两个关键设计：第一，内部节点只存索引键和指向子节点的指针，不存数据，所以一个页里能塞下大量键，树的高度被压得非常低；第二，所有的数据记录都存放在叶子节点，并且叶子节点之间用双向链表串起来，形成有序链表。这个链表设计太重要了，它是B+树支持范围查询、排序扫描的基础，也是哈希索引完全不具备的能力。

我算过一笔账，能直观感受B+树为什么适合海量数据。假设主键是8字节，指针6字节，那么一个16KB的页大概能存16KB / 14字节 ≈ 1170个键。假设一行业务数据约200字节，一个叶子页能存80条记录。两层内部节点能索引的叶子页数量是1170 × 1170，每个叶子页80条记录，算下来就是1170 × 1170 × 80 ≈ 1.09亿条。也就是说，亿级数据量的表，B+树只需要三层高度。查询时从根节点到叶子节点，最多三次磁盘IO，这还是在没有任何缓存的情况下。

2.3 索引存储和哈希存储的本质差异：有序还是无序

很多资料把哈希索引和B+树索引的差别归纳为“数据结构不同”，这个太笼统了。我更愿意用“索引存储和哈希存储”这个说法来对比，因为它的核心差异只有一个词：有序性。

B+树存储天然是有序的，叶子节点从左到右就是键的升序排列。这个有序性带来了一连串能力：范围查询可以直接定位下界，然后顺着链表顺序扫描到上界；排序操作可以借助索引顺序直接输出；分组聚合可以在扫描过程中连续累计相同键值；联合索引还能利用最左前缀原则，按索引键的顺序逐步缩小范围。可以说，数据库里大多数基于索引的优化，最终都回溯到“有序”这两个字上。

哈希存储则是无序的。它用散列函数把键打散到各个桶，换来了等值查询的极速定位，但代价是所有依赖顺序的操作都得另起炉灶。哈希存储不是不好，它只是把优化目标集中在了“点查”这一个能力上。这就决定了，在通用关系型数据库里，哈希索引适合做辅助，不适合做默认主索引。

3. 热搜词背后的痛点：范围查询、数据排序和索引争用

如果你去翻数据库相关的高频讨论，会看到不少类似“索引存储和哈希存储”“数据库开启审计引起索引争用”的议题。这些词看似分散，背后其实都对应着具体的线上事故或性能问题。我挑三个最有代表性的展开聊聊。

3.1 范围查询这条硬指标，基本把哈希索引“判死刑”

一个业务系统，最常出现的查询不是单点查，而是带条件的列表查。比如电商订单页，“查看我最近30天的订单”，翻译成SQL就是WHERE user_id = ? AND create_time >= ?。这种查询天然要求索引能快速定位到范围起点，然后连续扫描。

哈希索引对范围查询毫无办法。user_id经过哈希后，用户ID和时间顺序完全被打乱，就算你只查一个用户的订单，也没法保证时间相近的记录在物理上相邻。数据库只能把满足user_id条件的所有哈希桶都翻一遍，再逐条过滤时间条件。当用户订单量大时，这基本等于把哈希索引退化成扫描。

B+树联合索引就从容得多。以(user_id, create_time)为例，B+树先按user_id排序，在同一个user_id下再按create_time排序。查询时先精确命中user_id节点，随后沿着叶子链表顺序扫描，就能连续读到该用户的时间段内数据，磁盘IO也是顺序的，速度非常可观。这就是为何在绝大多数OLTP系统里，范围查询相关的慢SQL优化，最终都会落回B+树索引方案。

3.2 排序和分组：B+树叶子链表的隐藏价值

很多人排序慢的时候第一反应是给ORDER BY字段建索引，但说不清为什么。索引之所以能加速排序，是因为B+树索引本身已经按键有序，数据库扫描叶子链表时拿到的数据就是排好序的，可以直接省掉一次多路归并排序。反过来，哈希索引完全没有“顺序”的概念，ORDER BY只能老老实实把结果集取出来后排序。数据量一大，临时文件排序会拖垮整个查询。

分组操作同理。GROUP BY需要把相同键值的记录聚到一起统计，如果索引有序，连续扫描时相同值就在相邻位置，统计完一组切下一组，非常干净。哈希索引做不到这一点。哈希索引在分组上的唯一优势，反而是它可以先把数据散列到内存哈希桶里做初步聚合——注意，这是执行计划层面的Hash Aggregation，和索引本身的哈希结构是两码事，别混为一谈。

3.3 数据库开启审计后，为什么会出现索引争用

这个热搜词我特别有感触，因为真在线上遇到过。某次维护的系统响应突然变慢，数据库CPU没有明显飙高，但大量会话卡在等待事件上。排查后发现，业务侧为了合规开启了细粒度审计，每笔请求都要往审计日志表插入一条记录。审计日志表的主键索引是个B+树，大量并发插入都在向右递增，集中写入最右侧叶子节点，导致该页成为热页，频繁触发索引节点分裂和缓冲池中的并发竞争。这就是典型的高并发写热点引发的索引争用。

索引争用本质上是多个事务同时访问同一个索引页，互相等待锁或闩锁。B+树虽然有序性带来了查询优势，但写放大和热点也是它要付出的代价。哈希索引理论上能把插入分散到不同桶，降低热点，但需要提前预估数据规模、设计合理的桶数量，否则扩缩容时全量重哈希也是一场灾难。这个矛盾很有意思：B+树因为有序而强，也因有序而承受写热点；哈希存储因为无序而分散，也因无序而失去范围能力。

如果遇到审计场景下的索引争用，我通常会按下面几步排查和处理：

• 先看等待事件和热点对象，确认是索引页争用还是数据页争用。
• 检查索引增长方向，确认是否存在“单调递增键”导致的右侧热点。
• 评估审计日志的使用频率，考虑对日志表做分区，按时间分表。
• 对历史审计数据做归档，控制表中活跃数据的体量。
• 调整写入提交方式，降低单笔提交带来的索引维护频率。
• 在应用层对审计日志做缓冲批量写入，减少索引节点分裂次数。

数据库开启审计本身不是问题，问题在于它引入了新的写入模式，而原有索引结构没来得及适配。理解这一点，比盲目换个索引类型要实用得多。

4. 工程选型：哈希索引和B+树索引什么时候各占一头

聊完底层，回到实际问题：那哈希索引是不是就没用了？当然不是。工程选型的核心是看查询模式，而不是看结构热度。下面给出一套比较实用的判断框架。

4.1 哈希索引最香的几种场景

哈希索引最适合的，是单键等值查询占比极高、几乎不范围查询的场景。

第一类典型是键值型数据。比如用户会话Token、设备指纹、分布式锁等，这些数据的特征就是“按key存取，不关心顺序”。Redis一类内存数据库大量使用哈希结构，正是因为它把“点查”这一件事做到了极致，而且内存随机访问的代价远小于磁盘，无序带来的范围问题被刻意绕开。

第二类是MySQL的InnoDB自适应哈希索引。InnoDB内部会监控索引访问模式，如果发现某个B+树索引频繁走等值查询，会在内存中为它构建一个哈希索引，加速这些点查。但它只是B+树索引之上的“加速层”，不会取代B+树本身。这个设计非常巧妙：底层依然用B+树保证有序性和可靠性，上层用哈希缓存提升点查速度。 两者不是二选一，而是协作。

第三类是数据仓库里的哈希分布。在MPP数据库或分布式数据库中，经常按哈希键把数据打散到不同节点，实现并行扫描。这种场景追求的是数据在各节点间的均匀分布，而不是索引本身具备范围扫描能力，所以哈希策略很好用。

4.2 B+树索引不可替代的典型场景

只要你的查询SQL里出现范围条件、排序、分组、多列联合筛选，B+树就是更稳妥的选择。关系型OLTP系统里，大多数业务表都逃不开这些模式，所以B+树才成为事实上的默认索引。

还有一点经常被忽视：B+树索引对覆盖索引的支持非常友好。因为叶子节点存的是整行数据或者包含索引列的数据，某些查询可以只扫索引而不回表。哈希索引一般只存键和行指针，做不到这一点。覆盖索引省掉的回表IO，在高并发场景下效果立竿见影。

4.3 一张选型判断表

这个表不是绝对的。比如SSD时代随机读能力大幅提升，哈希索引在这类硬件上的整体表现会比机械盘好很多，但B+树的有序性优势依然在逻辑上不可替代。

4.4 “索引存储和哈希存储”怎么选，其实是个系统工程

很多人纠结要不要把某个查询的B+树索引改成哈希索引，我的建议是先别急着改。索引存储的选择，不只是换个数据结构，还牵涉到查询优化器、执行计划、统计信息、主外键约束等一系列联动。局部优化的前提，是先有全局的查询模式画像：这表有多少等值查询和范围查询？热点查询的返回行数是多少？写入并发有多大？有没有排序需求？

我见过一个团队，为了把一条点查SQL从5毫秒压到1毫秒，把普通索引改成了哈希索引。单条SQL确实提速了，但同一张表上其他范围查询全都走不了这个索引，系统整体吞吐反而下降了。这就是只盯着单点指标、没看整体负载的教训。哈希存储和B+树存储从来不是“谁取代谁”的关系，而是各自服务于不同的访问模式。

5. 生产环境里我踩过的三个索引坑，复盘给你看

最后分享几个真实踩坑记录，这些都是我线上环境亲手处理过的问题，比理论推导更能帮助理解两种索引的边界。

5.1 “哈希索引让慢查询消失”的错觉

有段时间我们做用户积分查询优化。当时积分表体量大，业务模式基本是“用户积分明细点查”，看起来很适合哈希索引。我建了哈希索引后，单独跑那条点查SQL，确实从几十毫秒降到了几毫秒。但报表需求一来，要按月份拉全量用户的积分变化趋势，查询计划完全没用上这个哈希索引，最后还是全表扫描加内存排序，直接打满临时表空间。

复盘时我才意识到，哈希索引优化的是“单点访问”，而报表需求本质上是“区域扫描”，二者需要的索引结构完全不同。正确的做法是保留B+树主索引，同时根据报表查询条件建一个(月份, 用户ID, 积分)的联合B+树索引，让扫描可以沿着叶子链表有序推进。

5.2 审计日志开启后的索引争用排查过程

回到前面说的审计场景。那次故障，刚开始大家都在查业务SQL有没有变化，走了弯路。后来看了数据库等待事件，发现大量会话在等待索引页相关的闩锁，锁定位到审计日志表的主键索引。审计功能的引入，意味着原来几乎只读的日志表突然变成了高频插入表，而且主键是自增ID，所有插入都往同一棵B+树的最右叶子节点挤。

处理方案不是改成哈希索引，而是改变写入模式。我们把审计日志从“每请求单条插入”改为“应用内存缓冲批量写入”，同时对历史审计数据做分区归档，把热数据控制在较小范围内。改造之后，索引争用明显下降，系统响应恢复稳定。这个案例让我深刻理解了一件事：索引争用很多时候不是索引结构本身错了，而是写入模式没匹配上索引的维护方式。

5.3 双索引结构在同一个业务里的配合

还有一个比较成功的案例。用户登录接口需要按手机号精确查用户，但后台管理页面需要按注册时间范围拉用户列表。我给用户表建了手机号唯一索引，这个索引可以走哈希加速；同时建了(注册时间, 用户ID)的B+树联合索引，支撑范围查询和排序。两个索引在一张表里各司其职，哈希索引负责点查加速，B+树索引负责范围与排序，配合起来整体性能非常理想。

这说明什么？哈希索引和B+树索引的“对决”只存在于纸面上。真实数据库的设计哲学是：在同一个表上，不同查询模式用不同索引，各取所长。 不要把心思花在争论谁更厉害上，而要把精力放在识别查询模式、设计匹配的索引组合上。

写在最后：选索引，本质是选访问模式的最优解

数据库索引没有绝对的王者，B+树之所以成为默认主索引，是因为它用一个有序结构同时满足了等值查询、范围查询、排序、分组、覆盖索引这些最常见需求，代价是写入时的树维护和潜在热点。哈希索引在点查上的速度无可匹敌，却天然放弃了对顺序操作的支撑。于我而言，每次做索引设计时，我都会先问自己一句：这个业务的访问模式，到底是“按key精确拿数据”多，还是“按范围连续取数据”多？答案出来，选型自然就清晰了。希望这篇把哈希索引与B+树索引从底到上拆完的文章，能帮你少走一些我走过的弯路。