MySQL 索引原理深度解析
索引是数据库性能优化的核心。理解索引的底层原理，才能写出高效的 SQL，做出正确的索引设计决策。
一、为什么选择 B+ 树？
MySQL InnoDB 使用 B+ 树作为索引结构，相比其他结构有显著优势：
- vs 二叉树：B+ 树高度低（百万数据仅3-4层），减少磁盘 IO
- vs B 树：B+ 树所有数据存在叶子节点，支持高效范围查询；叶子节点链表连接，顺序扫描性能极佳
- vs Hash：B+ 树支持范围查询和排序，Hash 只支持等值查询
二、聚簇索引 vs 非聚簇索引
InnoDB 中每个表有且只有一个聚簇索引（主键索引），数据行直接存储在 B+ 树叶子节点：
- 聚簇索引：叶子节点存储完整数据行，按主键顺序存储，主键查询无需回表
- 二级索引：叶子节点存储主键值，查询需要”回表”（先找主键，再查聚簇索引）
- 覆盖索引：查询的所有列都在索引中，无需回表，性能极佳
三、索引失效的常见场景
-- 1. 前导模糊查询 SELECT * FROM users WHERE name LIKE '%张%'; -- 索引失效 -- 2. 对索引列做函数运算 SELECT * FROM orders WHERE YEAR(created_at) = 2026; -- 失效 -- 优化：WHERE created_at BETWEEN '2026-01-01' AND '2026-12-31' -- 3. 隐式类型转换 SELECT * FROM users WHERE phone = 13800138000; -- phone是varchar，失效！ -- 4. 联合索引不满足最左前缀 -- 联合索引 (a, b, c)，WHERE b=1 AND c=2 无法使用索引
四、EXPLAIN 分析查询计划
使用 EXPLAIN 关键字分析 SQL 执行计划，重点关注：
type：ALL（全表）→ index → range → ref → eq_ref → const，从左到右性能递增key：实际使用的索引名rows：预估扫描行数，越小越好Extra：Using filesort、Using temporary 是性能警示信号
总结
索引设计没有银弹，需要结合具体的查询模式、数据分布和业务需求来决策。定期用 EXPLAIN 分析慢查询，是数据库优化的必备习惯。