SQL B+ 树索引的核心思想

B+树是专为磁盘I/O优化的多叉树结构，非叶子节点仅存键值和指针以降低树高，所有数据存储在叶子层且通过双向链表连接，支持高效范围查询与顺序扫描；其联合索引依赖最左前缀原则，且索引失效源于破坏键值有序性的操作。

为什么B+树不是B树，也不是二叉树

B+树是专为磁盘I/O优化的结构，不是为了内存查找快而设计的。它放弃“每个节点存数据”的直觉，转而让非叶子节点只存键值和子节点指针，这样一页（如InnoDB默认16KB）能塞下更多分支，树高自然压得更低——千万级数据通常只要3～4层，意味着最多4次磁盘读就能定位到记录。

• 二叉树在数据库里基本不用：树太高，一次查询可能要几十次磁盘IO
• 平衡二叉树（AVL）仍只有2叉，空间利用率低，页内键值数少，树高难压缩
• B树虽支持多叉，但非叶子节点也存数据，挤占了本可用于扩大扇出的存储空间
• B+树把所有数据“沉”到叶子层，非叶子层纯粹做导航，这是它矮胖、抗写、适合范围查询的根本原因

叶子节点连成双向链表到底有什么用

这个设计不是锦上添花，而是解决真实场景问题的关键：比如SELECT * FROM orders WHERE create_time BETWEEN '2025-01-01' AND '2025-01-31'，没有链表就得反复回树顶找下一个范围起点；有了next指针，查到第一个匹配叶子节点后，直接顺序往后扫，全程不跳回非叶子层。

• 范围查询（BETWEEN、>=、LIKE 'abc%'）性能跃升，避免多次随机IO
• ORDER BY + LIMIT 场景天然受益，例如翻页查询ORDER BY id LIMIT 10000,20
• 聚簇索引下，叶子节点存的是完整行数据，链表即物理顺序，极大减少磁盘寻道
• 注意：二级索引叶子存的是主键值而非整行，所以范围扫描后还需回表——这就是覆盖索引要解决的问题

联合索引为什么必须遵守最左前缀原则

因为B+树的搜索路径是单向递进的：从根节点开始，每一层都只按当前层级的键做二分查找，无法跳过某一层去“猜”下一层该比谁。联合索引(a, b, c)在内存中构建的是一棵以a为第一排序维度、b为第二、c为第三的树，a不等价于“过滤条件可选”，而是搜索入口的强制门槛。

• 支持：WHERE a = ?、WHERE a = ? AND b > ?、WHERE a =

  

  ? AND b = ? AND c IN (?,?)
• 不支持：WHERE b = ?（没a，根本进不了树的第二层）、WHERE a > ? AND c = ?（c在第三层，但第二层b未定界，无法确定c的有序区间）
• 隐式陷阱：WHERE a = ? AND c = ?看似用了两个字段，实际只能用上a，c被跳过，变成索引扫描而非索引查找

索引失效的三个典型瞬间

不是建了索引就万事大吉。B+树依赖“值的有序性”工作，任何破坏这种有序性的操作都会让引擎弃用索引，退化为全表扫描。

• WHERE name LIKE '%john'：前导通配符导致无法利用B+树叶节点的有序链表，必须逐行匹配
• WHERE YEAR(create_time) = 2025：函数计算使索引列create_time原始值不可见，优化器无法将查询条件映射到树中键值区间
• WHERE user_id = '123'（user_id是INT类型）：隐式类型转换触发全表扫描，MySQL会把每行user_id转成字符串再比，索引失效

这些不是配置问题，也不是版本bug，而是B+树结构本身决定的硬约束——它只认原始、有序、未加工的键值序列。