是个少女很多人刚开始接触数据库索引时，都会卡在同一个问题上：为什么所有主流关系型数据库的索引结构都选了B树和B+树这一脉？哈希表查找不是O(1)吗？二叉搜索树不是又简单又直观吗？数据库索引用B+树到底赢在哪？这个问题如果只停留在“B+树矮、B+树支持范围查询”这种背诵层面，过两天肯定忘。
我当年也是先把结论背下来应付面试，直到后来真正处理千万级表的慢查询、一条SQL从几百毫秒优化到几毫秒之后，才意识到B+树的每一个设计细节背后，都写着一笔关于磁盘IO、页存储和访问模式的现实账。这篇文章就把这笔账摊开算一遍，看完你不仅能回答面试，还能在日常建索引时多一些自己的判断。
1. 灵魂拷问：为什么不是哈希表，也不是二叉搜索树
1.1 哈希索引第一个出局
哈希表在等值查询上确实强得离谱，一个哈希函数算完，直接定位数据。数据结构课上我们都说哈希查找平均O(1)，那数据库为什么不用它当默认索引？
核心原因是：数据库的查询模式根本不是只有等值查询。
SELECT * FROM users WHERE age > 25 这种范围查询是家常便饭，但哈希函数的输出是散列的，它把原本有序的key值打散成了毫无规律的桶位置。请你告诉我，age大于25的所有记录，分布在哪些哈希桶里？答案是根本不知道，只能把所有桶全扫一遍。
再往下说，ORDER BY排序也用不上哈希索引，因为索引本身不按值有序。GROUP BY分组也一样，哈希索引没法提供有序扫描。甚至对于磁盘IO来说，哈希桶和链表里的数据物理位置是随机分布的，操作系统想帮你做预读都无从下手。
MySQL的InnoDB引擎里有个“自适应哈希索引”，它会在内存里自动为高频等值查询建一层哈希加速，但这只是B+树索引之上的锦上添花，它解决的问题是“缓存里的页查找速度”，而非磁盘上的完整数据索引。所以哈希索引能做辅助，成不了主索引。
1.2 二叉搜索树：内存里的优等生，磁盘上的差生
再看二叉搜索树。如果没有磁盘这堵墙，在内存里维护一棵红黑树或者AVL树，查找、插入、删除都是O(log n)，Java的TreeMap、C++的map都是这么干的。但数据库的数据量一上来，问题就绷不住了。
假设一张表有一亿条记录。一棵普通二叉平衡树的高度大约是log2(1亿)，算下来在26层左右。数据库每次向下访问一个节点，理论上就要把这个节点所在的页从磁盘读进内存，那就是大约26次磁盘随机读。机械硬盘一次随机读要10毫秒上下，26次就是260毫秒起步。这个延迟放在OLTP系统里，是不可接受的。
有朋友会说：那把整棵树都缓存进内存不就行了？但一亿条记录对应的索引结构本身就很大，内存根本扛不住全部缓存。就算热数据都在内存，冷数据查询依然会被打回原形。
所以二叉搜索树不是不好，它错在高度太高，而高度就是数据库的磁盘IO次数。数据结构教科书在内存模型下追求的比较次数优化，到了磁盘模型里全都得换算成页访问次数。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 磁盘的物理账本：页、预读与IO次数才是第一性原理
2.1 内存纳秒、磁盘毫秒：慢10万倍的差距意味着什么
要理解数据库为什么选B+树，先得理解一个事实：磁盘IO延迟和内存计算延迟之间的差距，不是一个量级，而是五六个量级。
CPU执行一条指令大约1纳秒，内存随机访问大约100纳秒，而机械硬盘一次随机读要10毫秒左右，固态硬盘好一些，但仍然要几十到上百微秒。做个不太严谨但直观的换算：如果一次内存访问是1秒，一次机械硬盘随机读差不多就是1天多。
这意味着什么？意味着数据库引擎优化时的首要目标，根本不是减少比较次数。你在内存里多比较100次，也就浪费几百纳秒；但如果少读一次磁盘，直接省下几毫秒甚至几十毫秒。所以在磁盘模型下，“IO次数”才是算法复杂度的真实度量。
2.2 从扇区到页：一次IO能带回多少数据
磁盘驱动器和固态硬盘都不是按字节寻址的。传统磁盘有扇区的概念，一次至少读512字节或4KB；SSD内部也有页的概念。操作系统文件系统更是一次读一个块或者多个块。到了数据库这一层，InnoDB默认的页大小是16KB。
也就是说，当数据库想读某一条记录时，至少要读一整个16KB页到缓冲池里。这反而是件好事：一次IO带回来的数据越多，单个页里能承载的路由信息就越多，下一次下探时就越可能直接命中。
这就是“页”与“索引节点”之间的天然对应关系。如果一种索引结构能让每个节点正好对应一个物理页，并且这个页里能装下足够多的后续路径信息，那一次IO就能完成一次节点访问，树的层数就是IO次数。
2.3 局部性原理给B+树开了外挂
存储系统里还有一个关键假设：如果你读了某个页，那么和它相邻的页大概率很快也会被读。这叫局部性原理。数据库在后台做预读时，经常会把相邻的多个页一起加载进缓冲池。
B+树的结构完美契合了这个原理。它的叶子节点按key有序排列，物理上相邻的数据大概率落在相邻页里。当你执行完一条范围查询，扫描完当前叶子页之后，顺着指针读下一个页，大概率数据已经因为预读被加载好了。哈希表做不到这一点，二叉树也做不到，因为它们的数据物理分布和逻辑顺序没有连续性。
所以“读尽量少的页”和“一次读回来的页要尽量有用”这两个原则，直接决定了后面B树和B+树的形态。
3. B树怎么让树变矮：多路平衡与溢出分裂
3.1 “阶”到底是什么，为什么直接决定树高
B树全称其实挺朴素，就是平衡多路搜索树。一个m阶B树，意思是每个节点最多有m个孩子，最多存m-1个key。二叉搜索树它的m等于2，每个节点最多两个孩子，永远只有两个分叉，所以它是一棵“2路树”。
B树把m放开之后，树形从又高又瘦变成了又矮又胖。判断数据结构在磁盘上的表现，核心指标就是“扇出”——一个节点能带出多少个孩子分支。二叉树扇出固定是2，而一个m为1000的B树，每个节点最多能带出1000个孩子。
这里有个直白的换算：如果每个节点有d个分叉，那么树的高度大约是logd(N)。二叉树查1亿条数据要26层，而d=1000的时候，log1000(1亿)约等于3层。从26次IO降到3次IO，这就是B树对数据库最原始的吸引力。
3.2 一根16KB的页能塞下多少个路由项
你可能会问，d=1000是不是拍脑袋想出来的？还真不是，它受限于物理页的大小和key的大小。
以InnoDB为例，一个数据页默认16KB。B树的非叶子节点里，存的不是用户数据，而是“key + 指向子节点的指针/页号”。假设你的主键是BIGINT类型，占8字节，子页指针再占6到8字节，算上一个key项大约十几字节。那么一个16KB页大约能装下1000个左右的路由项。
当然这是粗略估算，实际页里还有页头页尾、槽位等信息，填充率也不是100%，但数量级就是1000。
所以一棵B+树，通常只要两到三层，就能覆盖千万到亿级别的数据量。这也是为什么很多数据库资深DBA常说“B+树三层左右能撑住千万级表”——这句话前面一定要加上“默认页大小、int/bigint主键”这两个限定条件，后面章节我会专门展开。
3.3 插入会溢出，溢出就分裂：B树保持平衡的方式
B树维持平衡靠的不是像AVL树那样左旋右旋，而是靠“分裂”和“合并”。
简单描述插入过程：先沿着树查找目标叶子位置，把新key按大小插进去。插入之后如果节点上的key数量还没超过上限m-1，直接结束。如果插满了，就从中间位置挑一个“中位key”，把当前节点一分为二，中位key上提到父节点，原来的左右两半变成父节点的两个子节点。
麻烦的是，父节点多加了一个key之后，它也可能溢出，于是继续向上分裂。如果一路裂到了根节点，根节点也被撑爆，那就要新建一个根节点，把原根的中位key放进去，让树整体长高一层。反过来，删除时如果节点key数量低于下限，就会先尝试向兄弟节点借一个key，借不到就把两个节点合并，再向上调整。
这个机制天然保证了B树“所有叶子都在同一层”，不会像二叉搜索树那样退化成长链表，也不会有某些节点特别深、某些特别浅的不稳定状态。面试时如果你能把“分裂时中位key上提”这个过程讲清楚，会比背一堆旋转操作更有说服力。
4. B+树改良了什么：数据下沉与叶子链表
4.1 内部节点只做路标，数据全部下沉到叶子
B树和B+树最核心的区别，不是谁多一个加号，而是数据存放策略完全不同。
B树的每个节点既可以存key，也可以存数据（或者指向数据行的指针），也就是说你查询时可能在非叶子节点就命中结果并直接返回。B+树则把规则改死了：所有数据都放在最底层的叶子节点上，内部节点只存key和子页指针，纯粹当路标用。
这个改动乍一看不是更麻烦吗？明明B树可以在中间层提前返回，B+树却必须走到叶子才能拿到数据。确实，在点查询上B+树可能比B树多走一层，但这点代价换来的收益是巨大的。
第一个收益是内部节点更轻，扇出更高。因为非叶子节点不用存数据，一个16KB页能装下更多路由项。如果B树节点里存的是大字段数据，一页可能只能塞几条记录，树会瞬间变得又高又大。而B+树无论业务表的数据行有多大，内部节点始终保持轻盈，树的高度被压得很低。
第二个收益是查询延迟更稳定。B树里某些key在中间层就命中了，另一些key要走到叶子才命中，每次查询的IO次数忽高忽低，存储引擎很难做稳定的IO预算。B+树所有查询都必须走完同样的层数，路径长度一致，行为可预期得多。
4.2 叶子链表：范围查询的胜负手
如果说数据下沉是让B+树变矮，那叶子之间用链表串起来，就是让范围查询起飞的关键设计。
B+树的叶子节点按key有序排列，并且每个叶子页都有指向下一页和上一页的指针。在InnoDB里这是一个双向链表。为什么要这样？
因为当数据库执行范围查询时，比如WHERE create_time BETWEEN '2024-01-01' AND '2024-01-31'，B+树的搜索过程是：先定位到第一个符合条件的最小key在哪个叶子页，然后沿着叶子链表一个一个往后面读，直到超过范围为止。整个过程中，除了第一步需要从根走到叶子，后面全部是顺序扫描。
如果换成B树，范围查询完全就是另一个故事了。B树的数据分散在树的不同层，想要拿到一段有序区间，你必须做中序遍历。走完一个节点的左子树，要回溯到父节点，再钻进右子树，树越高回溯越深。这种来回跳跃在磁盘上就是大量随机IO。
多说一句：为什么数据库范围查询的代价能压得这么低，其实还有一个底层因素，就是前面说的局部性原理。叶子节点逻辑上相邻的数据，物理上也有很大概率落在相邻页，顺序读这几个页时，操作系统预读和存储引擎的预取都能发挥作用。
4.3 一个直白的对比表
我把B树和B+树的核心差异整理成一张表，平时答疑时也经常贴这张：
| 对比维度 | B树 | B+树 |
|---|---|---|
| 数据存储位置 | 内部节点和叶子节点都可能存 | 只存叶子节点 |
| 内部节点空间占用 | 较高，可能存整行/大字段 | 很低，只存key+指针 |
| 相同数据量下树高 | 更高 | 更矮 |
| 范围查询方式 | 中序遍历+反复回溯 | 叶子链表顺序扫描 |
| 查询路径稳定性 | 不稳定，中间层可能命中 | 稳定，每次都要到叶子 |
| 磁盘随机IO友好度 | 一般 | 优秀 |
这个对比已经能回答“数据库为什么选B+树而不是B树”中80%的问题了。剩下20%要去真实的存储引擎和SQL执行计划里看。
5. InnoDB实操走查：一条查询如何沿B+树命中数据
5.1 聚簇索引其实就是一棵“大B+树”
以InnoDB为例，你给一张表建了主键后，InnoDB会为主键自动创建一个聚簇索引。这个聚簇索引本身就是一棵B+树，树的所有叶子节点存的是完整的用户记录行。换句话说，这张表的“数据文件”和“主键索引”是同一棵树，不需要额外回表。
默认情况下你可以简单理解：整张表按主键顺序被组织在一棵B+树里，范围扫描主键就是顺序扫数据本身。
我们建一张简单的测试表：
sql复制CREATE TABLE users (
id BIGINT NOT NULL AUTO_INCREMENT,
user_name VARCHAR(64) NOT NULL,
age INT NOT NULL,
PRIMARY KEY (id),
KEY idx_age (age)
) ENGINE=InnoDB;
这里的主键id对应一棵聚簇B+树，年龄字段上的idx_age对应一棵二级索引B+树。两者的叶子节点内容不一样，这是理解InnoDB索引使用逻辑的关键。
5.2 从根页走到数据页的完整路径
执行这条SQL：
sql复制SELECT * FROM users WHERE id = 102400;
InnoDB内部的路径大概是这样的：
第一步，读取聚簇索引的根页。根页位置固化在表空间内部，不需要额外搜索。根页是一个非叶子节点，里面按照主键顺序存了若干key和下一层页号。InnoDB会在页内通过二分或者线性搜索，定位到102400落在哪个子页区间。
第二步，根据区间找到第二层的页号。如果第二层还不是叶子页，继续在这一页内二分查找，确定第三层页号。绝大多数情况下，到第三层就已经是叶子页了。
第三步，读叶子页。叶子页里不仅有序存着主键，还存着完整的行记录。页内有页目录slot，通过二分定位到记录槽，然后把记录返回给上层。
整个过程如果所有页都在缓冲池里，可能只需要在内存里做几次页查找。如果缓冲池没命中，真正发生磁盘IO的往往只有最后那一次叶子页读取，因为根页和上层中间页都是高频热页，基本长期驻留在缓冲池中。这就是为什么一条主键等值查询在千万级表上通常都能跑到毫秒级。
5.3 二级索引、回表与覆盖索引
再来一条SQL：
sql复制SELECT id, age FROM users WHERE age = 30;
这条走了idx_age这棵二级索引B+树。二级索引的叶子节点里存的不再是整行记录，而是“索引列age + 主键id”。所以InnoDB可以直接从这棵B+树里找到所有age=30对应的id值。
这条查询需要的列只有id和age，正好都在二级索引的叶子页里，InnoDB不需要再去主键索引B+树里查一遍完整行。这种“查询列全部可以从索引里拿到”的情况，叫做覆盖索引。EXPLAIN里Extra字段会显示Using index。
如果换成SELECT * FROM users WHERE age = 30，二级索引叶子页里没有完整行，InnoDB必须先拿id去聚簇索引B+树再查一次，这叫回表。回表不是一定很慢，一次主键点查通常也就多一两次页访问，但如果回表行数很多，性能就明显下降。