面试通关特训营第二天 ✅

大家圣诞快乐！我是无情的前端试炼师。虽然主职是前端，但最近决定挑战一下数据库领域。对于我来说，探索 MySQL 有点像参加邻居家圣诞派对：有点不熟悉，但满是新鲜感和学习的乐趣。

今天参加了数据库试炼营的 MySQL 专场，任务是解锁三道经典问题：
1）MySQL 三层 B+ 树能存多少数据？
2）MySQL 索引的最左前缀匹配原则是什么？
3）为什么 MySQL 选择使用 B+ 树作为索引结构？

以下是我的一些学习心得，和大家一起过个有知识陪伴的圣诞节，如果哪里说得不对，欢迎大神们指正！

MySQL 三层 B+ 树能存多少数据？

B+ 树的设计是为了优化磁盘 I/O，尤其是在数据库这种海量数据场景中特别适用。默认情况下，InnoDB 页大小是 16KB，假设每条记录 1KB，那么叶子节点每页能存 16 条记录。再往上是内部节点，只存键值和指针，假设一条记录占 10 个字节，那么一页内部节点大概能存 1600 条指针。整个三层结构是这样的：

• 根节点指向 1600 个中间节点；
• 每个中间节点再指向 1600 个叶子节点；
• 每个叶子节点存 16 条记录。

这样总容量就是 ，约 4096 万条记录。虽然实际情况会受到页分裂、填充率和字段长度变化的影响，但理论上这个量级足以覆盖大多数应用场景。

MySQL 索引的最左前缀匹配原则是什么？

最左前缀匹配原则的核心是顺序性。假设有一个联合索引 (a, b, c)，MySQL 在查询时会从最左边的字段开始依次匹配。

• 比如 WHERE a = 1，索引可以用；
• WHERE a = 1 AND b = 2 也能用；
• 但如果直接写 WHERE b = 2 或 WHERE c = 3，索引就失效了，因为跳过了最左边的字段 a。

范围查询中断匹配的情况也需要特别注意，比如 WHERE a = 1 AND b > 2 AND c = 3，索引会匹配到 (a, b)，但 c = 3 无法再利用索引。设计联合索引时，字段顺序要根据查询频率优先级来安排，不然可能导致索引形同虚设。

为什么 MySQL 选择使用 B+ 树作为索引结构？

B+ 树特别适合数据库这种需要频繁读取和范围查询的场景。它的节点大小和磁盘页对齐，访问时可以一次性读写一整页，大幅降低了磁盘 I/O 次数。再加上内部节点只存键值和指针，分支因子特别大，树的高度很低，三层或四层 B+ 树就能存储上亿条数据。

还有一点是它的叶子节点之间是按顺序用链表连接的，这让范围查询变得非常高效。比如 WHERE id BETWEEN 10 AND 20，找到起点后直接顺着链表读就行，不需要频繁回到树的结构中重新查找。相比 B 树，B+ 树把所有数据集中放在叶子节点，访问路径统一，更适合数据库的高并发访问和批量读取需求。