这是 SQL 学习路线的收官篇。前面学了索引、事务、锁、存储过程，今天把它们串起来：一条慢 SQL 到手，如何系统地定位、分析、优化？掌握这套方法论，你就能从「会写 SQL」进阶到「能救慢查询」。
场景引入
线上告警：orders 表 500 万行，下面这条查询跑了 12 秒：
SELECT o.id, o.order_no, u.name
FROM orders o
LEFT JOIN users u ON o.user_id = u.id
WHERE o.status = 'PAID'
AND o.created_at > '2026-06-01'
ORDER BY o.created_at DESC
LIMIT 20;
优化四步法
第 1 步：EXPLAIN 看执行计划
EXPLAIN SELECT ...; -- 同上 SQL
-- 关键输出
-- type: ALL ← 全表扫描，最差
-- key: NULL ← 没走任何索引
-- rows: 5000000 ← 扫了 500 万行
-- Extra: Using filesort ← 排序没走索引，额外文件排序
看懂 type 优先级（好→坏）：
system > const > eq_ref > ref > range > index > ALL
看到 ALL 或 index 且 rows 巨大，就是优化信号。
第 2 步：补索引，消除全表扫描
-- status + created_at 复合索引：WHERE 过滤 + ORDER BY 排序一次搞定
ALTER TABLE orders ADD INDEX idx_status_created (status, created_at);
-- 再次 EXPLAIN：
-- type: ref | key: idx_status_created | rows: 12000
-- Extra: 不再有 Using filesort ✅（排序已走索引）
索引设计要点：
- 等值条件放前面（
status），范围条件放后面（created_at）——最左前缀原则 - 让
ORDER BY直接吃索引，消灭filesort - 区分度高的列优先（
status只有几个值，单独建索引意义不大，必须和其他列组合）
第 3 步：改写 SQL，减少无效开销
-- ❌ 原写法的问题：
-- 1. SELECT 不需要的列（o.* 会拖累回表）
-- 2. LIMIT 20 但排序要排完所有匹配行
-- ✅ 优化后：
SELECT o.id, o.order_no, u.name
FROM orders o
INNER JOIN users u ON o.user_id = u.id -- 业务上 LEFT JOIN 可改 INNER
WHERE o.status = 'PAID'
AND o.created_at > '2026-06-01'
ORDER BY o.created_at DESC
LIMIT 20;
其他高频改写：
- 避免
SELECT *：只取需要的列，减少回表和网络传输 - 深分页优化：
LIMIT 100000, 20改成子查询定位游标SELECT ... FROM orders WHERE id > (SELECT id FROM orders ORDER BY id LIMIT 100000, 1) ORDER BY id LIMIT 20; - 函数包裹列会废索引：
WHERE YEAR(created_at) = 2026→ 改成范围条件created_at >= '2026-01-01' AND created_at < '2027-01-01'
第 4 步：用慢查询日志验证
-- 开启慢查询日志（MySQL）
SET GLOBAL slow_query_log = ON;
SET GLOBAL long_query_time = 1; -- 超过 1 秒的记录
-- 优化后实测：12s → 80ms，rows 从 500 万降到 1.2 万
注意事项
- ⚠️ 索引不是越多越好：每个索引都拖慢写入，冗余索引（
(a,b)与(a)）要定期清理 - ⚠️
LIKE '%xxx'前置通配符不走索引；OR连接的条件可能放弃索引，可用UNION ALL拆分 - ⚠️ 数据量小时（万级以内）全表扫描可能比走索引更快，先 EXPLAIN 再动手，别盲目加索引
- 💡
EXPLAIN ANALYZE（MySQL 8.0+）能给出实际执行时间和行数，比单纯 EXPLAIN 更接近真相 - 💡 线上优化套路：慢查询日志 → 找 Top N 慢 SQL → EXPLAIN → 补索引/改写 → 回归验证，形成闭环
总结
25 天路线收官：从 SELECT 语法到索引原理，从事务隔离到锁机制，最后落到查询优化实战——SQL 的核心不是「会写」，而是「写得快、写得稳」。这套 EXPLAIN 排查流，就是你在生产环境最常用的看家本领。🎉
