MySQL索引优化实战：从B+树原理到慢查询排查

我最早真正意识到“索引”这两个字值多少钱，是在一次线上事故复盘。那是一个刚上线不久的业务报表模块，数据量还不到一千万行，可一个列表查询接口愣是从 200ms 涨到了 2.3s，数据库 CPU 直接飙到 80%。当时的解决方式简单粗暴——DBA 用一条 ALTER TABLE 加了个索引，接口瞬间掉回 80ms。那次之后我就明白了一个道理：MySQL 性能优化，90% 的收益都压在索引上，而索引优化的核心是“理解数据在磁盘上的组织方式，再用最小成本把要的数据拿回来”。

这篇内容我准备系统讲一遍 MySQL 索引优化，从 InnoDB 的底层存储逻辑，到建索引的分析方法，再到索引失效和慢查询排查，最后是索引运维里那些文档不会写的坑。内容适合刚接触索引优化、想搞懂原理的新手，也适合写了好几年 SQL 但没仔细抠过执行计划的开发，以及正在排查线上慢 SQL 的运维/后端同学。

1. 索引到底是什么，为什么能让查询“快成闪电”

很多人背过“索引是 B+ 树”“索引能加速查询”，但问到为什么 B+ 树就比全表扫描快，就支支吾吾了。我觉得搞懂索引优化的前提，是先搞懂两个问题：没有索引时 MySQL 在做什么，有索引时它又在做什么。

1.1 全表扫描的真实成本：磁盘 IO 才是命门

先看没有索引的情况。MySQL 的 InnoDB 存储引擎把数据放在磁盘上，最小读写单位是 16KB 的数据页。假设一张用户表有 1000 万行数据，每行数据大约 300 字节（包含各种用户字段），那么一个数据页大概能装 50 行，这张表总共需要约 20 万个数据页。

如果 SQL 是 SELECT * FROM user WHERE name = '张三'，而 name 列上没有索引，MySQL 只能把 20 万个数据页逐一从磁盘读入内存，逐行比对 name 字段。就算每次磁盘 IO 只要 10ms（SSD 实测随机读大概 0.1ms，机械盘会慢很多），20 万次 IO 算下来也要 20 秒起步——这就是慢查询的根源。

这里有个关键概念：磁盘随机 IO 比顺序 IO 慢几个数量级。全表扫描本质上是大量随机读取，而索引的核心价值，就是把“随机读”尽可能变成“少量精确读”。

1.2 为什么偏偏是 B+ 树，而不是哈希或二叉树

MySQL 索引默认选择 B+ 树，不是偶然。核心原因有三个：

• 矮胖结构，查询次数少：B+ 树是典型的多叉平衡树，一个节点（对应一个 16KB 数据页）能存几百上千个键值。以主键 bigint 为例，一条记录大概 8 字节，加上指针 6 字节，一页能存约 1000+ 个键值对。三层 B+ 树大约能存 2000×2000×叶子页容量，轻松覆盖千万级数据。也就是说，走索引查询只需要 3~4 次磁盘 IO，和全表扫 20 万次 IO 是天壤之别。
• 叶子节点有序链表：B+ 树所有数据都存在叶子节点，且叶子节点之间通过双向指针串联。这保证了范围查询（比如 WHERE age BETWEEN 18 AND 30）和排序查询（ORDER BY age）都可以像读链表一样顺序扫描，极大提升性能。
• 非叶子节点不存数据，只存索引键：这让每页能容纳更多键值，树的层数更低，IO 次数更少。

作为对比，哈希索引虽然单次精确查找（WHERE id = 100）能做到 O(1)，但它不支持范围查询，也不支持排序，所以在 OLTP 场景下 B+ 树是更通用的方案。

1.3 聚簇索引和二级索引：回表到底是怎么回事

InnoDB 里有两类索引，理解它们的差异，才能明白为什么“不能乱建索引”。

• 聚簇索引（Clustered Index）：表按主键组织，聚簇索引的叶子节点直接存储整行数据。如果没有显式主键，InnoDB 会选第一个非空唯一索引作为聚簇索引；如果也没有，就生成隐藏的 rowid 作为聚簇索引。所以主键就是数据的物理存储顺序，这也是为什么强烈建议使用自增整型主键——写入时顺序追加，避免页分裂。
• 二级索引（Secondary Index）：叶子节点不存整行，而是存“索引列的值 + 主键值”。查询时如果只靠二级索引拿不到完整行数据，就需要拿着主键去聚簇索引再查一次，这个过程叫回表。

打个比方：聚簇索引是书的正文页，二级索引是书末的“术语索引表”。查“索引”这个词，先去术语表找到它在第 200 页，再翻到第 200 页看正文，这就是回表。如果术语表中直接附带了完整解释，就不用翻正文了——这就是后面的“覆盖索引”能大幅提速的原因。

2. 索引设计之前，先学会用 EXPLAIN 读懂一条 SQL

建索引不是拍脑袋，而是“先诊断、再用药”。我见的很多开发同学，拿到慢 SQL 第一反应就是加索引，加完也不知道有没有生效。正确做法是先用 EXPLAIN 看执行计划，搞清楚 MySQL 对这条 SQL 的访问路径，再来设计索引。

2.1 EXPLAIN 输出到底该怎么读

拿一条实际 SQL 举例：

sql复制EXPLAIN SELECT id, name, age FROM user WHERE status = 1 ORDER BY create_time DESC LIMIT 20;

输出里有几个核心列需要关注：