一次讲透数据库索引：B+ 树、最左前缀与索引失效

数据库索引不是“加了就快”。这篇笔记讲清楚 B+ 树索引到底怎么工作、什么时候会失效，帮你避开最常见的几个误区。

为什么是 B+ 树，不是哈希表

哈希索引查单个等值确实快，但它有个致命短板：不支持范围查询，也不支持排序。而真实业务里 WHERE created_at > ?、ORDER BY id 这类需求占大头。B+ 树把数据按顺序组织在叶子节点上，并用链表把叶子串起来，于是等值、范围、排序、前缀匹配全都能走索引。这就是为什么绝大多数关系库默认用 B+ 树而不是哈希。

最左前缀：联合索引的核心规则

假设你建了联合索引 (a, b, c)，它本质上是按 a，再按 b，再按 c 排好序的一棵树。由此推出「最左前缀」规则：

• WHERE a = 1 ✅ 走索引
• WHERE a = 1 AND b = 2 ✅ 走索引
• WHERE b = 2 ❌ 用不上（跳过了最左的 a）
• WHERE a = 1 AND c = 3 ⚠️ 只能用到 a 这一段，c 得回表过滤

记住一句话：索引只能从最左列开始连续使用，中间断了后面就用不上。

这些写法会让索引失效

1. 对索引列做运算或函数：WHERE YEAR(created_at) = 2026 用不上索引，改成 WHERE created_at >= '2026-01-01' AND created_at < '2027-01-01'。
2. 隐式类型转换：phone 是字符串却写 WHERE phone = 13800000000，数据库会把整列转类型，索引作废。加上引号。
3. 前导模糊匹配：LIKE '%关键词' 无法走索引；LIKE '关键词%' 可以。
4. OR 连接非索引列：WHERE a = 1 OR d = 2，只要 d 没索引，整条大概率全表扫。

覆盖索引：省掉回表这一步

普通二级索引命中后，还要拿主键回聚簇索引取完整行，这叫「回表」。如果你要查的列刚好都在索引里，数据库直接从索引返回，不用回表——这就是覆盖索引。给高频查询按「查询涉及的列」设计联合索引，能显著减少 IO。用 EXPLAIN 看到 Using index 就说明命中了覆盖索引。

不要为了索引而索引

索引会拖慢写入（每次增删改都要维护索引树），也占空间。区分度低的列（比如性别）单独建索引基本没用。正确姿势是：先用慢查询日志找出真正的热点 SQL，再用 EXPLAIN 确认执行计划，最后按需补索引——而不是一上来给每列都加。