MySQL 索引与执行计划：从 EXPLAIN 看懂慢查询

读懂 EXPLAIN#

1
EXPLAIN SELECT id, name FROM user WHERE age = 25 AND city = 'Shanghai';

重点关注几列：

• type：访问方式。从好到差大致是 const > ref > range > index > ALL。出现 ALL 意味着全表扫描。
• key：实际使用的索引。
• rows：预估扫描行数，越小越好。
• Extra：Using index 表示覆盖索引；Using filesort、Using temporary 需要警惕。

最左前缀原则#

联合索引 (city, age, name) 可以支撑：

• WHERE city = ?
• WHERE city = ? AND age = ?
• WHERE city = ? AND age = ? AND name = ?

但无法有效支撑只写 age 或 name 的查询。设计联合索引时，把区分度高、使用频率高的列放在前面。

覆盖索引#

如果查询的列都在索引里，MySQL 不需要回表：

1
-- 索引 (city, age, name)
2
SELECT city, age, name FROM user WHERE city = 'Shanghai';

回表是随机 IO，能避免就避免。

常见的索引失效场景#

1. 对索引列使用函数或运算：WHERE DATE(create_time) = '2026-01-01'。
2. 隐式类型转换：字符串列用数字去比较。
3. 以通配符开头的模糊查询：LIKE '%abc'。
4. OR 连接的条件中，有一边没有索引。
5. 联合索引没有遵循最左前缀。

分页深翻页#

1
-- 慢：需要扫描并丢弃前 100 万行
2
SELECT * FROM orders ORDER BY id LIMIT 1000000, 20;
3

4
-- 快：利用上一页的最后一个 id
5
SELECT * FROM orders WHERE id > 1000000 ORDER BY id LIMIT 20;

小结#

优化的流程很朴素：先定位慢 SQL，再看执行计划，然后调整索引或改写查询，最后用真实数据验证。不要为了加索引而加索引，每个索引都会拖慢写入、占用空间。