索引是数据库优化的核心，而 B+ 树是 InnoDB 的索引骨架。理解它，你就掌握了 MySQL 调优的半壁江山。“给表加个索引吧” —— 这大概是 DBA 和开发之间最常出现的对话。但你是否想过：为什么 MySQL 的索引选择了 B+ 树，而不是哈希表、二叉树、B 树？为什么联合索引有“最左前缀”原则？为什么一条 SQL 明明有索引却还是慢？这些问题，都指向同一个底层答案：B+ 树的实现细节决定了索引的行为。本文将带你从零构建 B+ 树的世界观，深入 InnoDB 索引的实现，并用大量实战案例剖析索引的“是与非”。全文约 8000 字，建议收藏后反复阅读。一、为什么是 B+ 树？—— 从磁盘 I/O 说起1.1 内存与磁盘的速度鸿沟内存访问：纳秒级（~100ns）磁盘寻道：毫秒级（~10ms）两者相差约10万倍。对于数据库这种大规模数据存储，减少磁盘 I/O 是性能的关键。索引的作用，就是提供一种高效的数据组织方式，让查找数据时能够跳跃式地访问磁盘，而不是全量扫描。1.2 二叉树为什么不行？二叉查找树：最坏情况下退化为链表（如插入