慢SQL优化

一、MySQL Explain 核心字段精讲（面试必背，只记重点）

1. id
   SQL执行顺序，id越大越先执行；相同从上到下执行。
2. select_type
   simple简单查询、primary主查询、subquery子查询、union联合查询。
3. type（重中之重）
   性能从优到劣：
   system > const > eq_ref > ref > range > index > ALL

• 目标：至少达到 range/ref
• 大忌：ALL 全表扫描，必须优化

4. key
   真正最终命中使用的索引；为NULL说明没走索引。
5. key_len
   索引有效长度，判断联合索引利用率。
6. rows
   预估扫描行数，越小越快。
7. Extra（高频优化点）

• Using filesort：文件排序，没走索引排序，CPU高 → 必建有序联合索引
• Using temporary：临时表，一般group by/distinct导致 → 优化索引+拆分SQL
• Using index：覆盖索引，无需回表，性能优秀

---

二、真实慢SQL + 优化前后案例（Java面试实战版）

案例1：普通全表扫描优化

原慢SQL（烂写法）

SELECT * FROM user WHERE phone = '13800138000';

问题：phone无索引 → type=ALL 全表扫描

优化：

CREATE INDEX idx_phone ON user(phone);

效果：type=ref、命中索引、扫描行数暴跌

---

案例2：索引列函数导致失效

原慢SQL

SELECT * FROM order_info WHERE DATE(create_time) = '2026-03-29';

问题：索引列套函数 → 索引失效全表扫

优化改写：

SELECT * FROM order_info 
WHERE create_time >= '2026-03-29 00:00:00' 
  AND create_time < '2026-03-30 00:00:00';

---

案例3：Like左模糊索引失效

原：

SELECT name FROM customer WHERE name LIKE '%张三%';

优化：普通索引无解，正文检索丢 ES 实现；

若右模糊 LIKE '张三%' 可正常走索引。

---

案例4：深分页 limit 超大偏移 经典优化

慢SQL

SELECT * FROM orders LIMIT 100000,10;

底层扫描10w+行再丢弃，极慢

优化（主键定位跳转）：

SELECT * FROM orders WHERE id > 100000 LIMIT 10;

---

案例5：Using filesort 排序优化

慢SQL：

SELECT id,title FROM goods WHERE category_id=10 ORDER BY sort_num;

无联合索引 → 文件排序

建联合索引解决：

CREATE INDEX idx_cat_sort ON goods(category_id,sort_num);

等值+顺序，直接索引有序返回，消除 filesort

---

案例6：避免select * + 回表优化为覆盖索引

慢：

SELECT * FROM user WHERE mobile='13800013800';

优化指定字段 + 覆盖索引：

SELECT id,mobile,age FROM user WHERE mobile='13800013800';
CREATE INDEX idx_mobile_cover ON user(mobile,age);

Extra出现 Using index，无回表，速度拉满

---

三、连贯口述总结（直接背面试）

我排查慢SQL首先用 Explain 分析执行计划，重点看 type 是否全表扫描、key 是否命中索引、rows 扫描行数、Extra 是否出现 Using filesort / Using temporary。

常见问题比如：索引列函数运算、左模糊like、隐式类型转换都会造成索引失效，我会改写SQL条件；深分页用主键ID偏移优化；group by、order by 不合理引发临时表和文件排序，就设计「等值+排序」联合索引。

同时杜绝 select *，用覆盖索引减少回表；大表冷热分离、归档减负，架构侧配合Redis缓存、读写分离、分库分表、统计查ClickHouse/ES，多层落地完成整体SQL与数据库性能优化。