慢查询怎么优化？EXPLAIN 的结果怎么看？

详细解析#

定位慢 SQL#

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;                  -- 超过 1 秒就记录，默认是 10 秒
SET GLOBAL log_queries_not_using_indexes = 'ON'; -- 可选：记录没有使用索引的查询

慢日志中的每条记录类似这样：

# Query_time: 2.315042  Lock_time: 0.000105 Rows_sent: 10  Rows_examined: 1000000
SELECT * FROM orders WHERE user_id = 1001 AND status = 1 ORDER BY create_time DESC LIMIT 10;

Rows_examined 远大于 Rows_sent，说明扫描了大量用不上的行，这是最典型的优化信号。日志多时用 mysqldumpslow 或 pt-query-digest 按 SQL 模板汇总，先优化总耗时最高的几类。

EXPLAIN 的关键列#

type 从好到差：

Extra 的常见值：

• Using index：覆盖索引，不用回表
• Using where：存储引擎返回的行还要在 Server 层按 WHERE 过滤，单独出现不说明好坏
• Using index condition：用了索引下推，见 聚簇索引和回表
• Using filesort：没法利用索引的顺序，需要额外排序，数据多时会用到磁盘临时文件
• Using temporary：用了临时表，常见于没有合适索引的 GROUP BY、DISTINCT，以及需要去重的 UNION

EXPLAIN 不执行语句，给出的都是估算。MySQL 8.0.18 起可以用 EXPLAIN ANALYZE，它会真正执行语句，输出每一步的实际耗时和行数。

常见的优化手段#

1. 建合适的索引：按 WHERE 的等值列、范围列和 ORDER BY 设计联合索引，哪些写法会让索引失效见 最左前缀和索引失效
2. 避免 SELECT *：只查需要的列，才有机会用上覆盖索引，也能减少网络传输
3. 改写子查询：MySQL 5.6 起，优化器能把很多 IN (子查询) 自动转成半连接，不必见到子查询就改；但 select_type 为 DEPENDENT SUBQUERY 的相关子查询会对外层的每一行执行一次，可以改写成 JOIN
4. 拆分大操作：一次删除几百万行会长时间持有锁、产生巨大的事务，改成按主键范围分批，每批几千行
5. 优化分页：LIMIT 偏移量很大时，扫描和回表的代价都很高，见 深分页怎么优化

代码示例#

orders 表约 100 万行，只有主键索引：

EXPLAIN SELECT * FROM orders
WHERE user_id = 1001 AND status = 1
ORDER BY create_time DESC LIMIT 10;

-- 按"等值列在前、排序列在后"建联合索引
ALTER TABLE orders ADD INDEX idx_user_status_time (user_id, status, create_time);

加索引前后的 EXPLAIN（示意）：

加索引后，user_id 和 status 等值定位到一小段索引，这一段里 create_time 本身就是有序的。InnoDB 可以反向扫描这段索引，直接按时间倒序取 10 条，不再需要排序，MySQL 8.0 的 Extra 会显示 Backward index scan。MySQL 8.0 还真正支持了降序索引，也可以直接建成 (user_id, status, create_time DESC)，正向扫描比反向扫描效率略高。

面试官可能追问#

易错点#

• type 为 index 不代表索引用得好，它是扫描整个索引，和 ALL 一样是全扫描
• Using where 不等于没走索引，要结合 type 和 key 一起看
• EXPLAIN ANALYZE 会真正执行语句，不要随手用在写操作上
• SET GLOBAL long_query_time 只对之后新建的连接生效，当前连接要用 SET SESSION