一、调优基础必考题

1. 索引优化三连问（必考指数⭐⭐⭐⭐⭐）

场景题：现有订单表order_info，包含字段（order_id,user_id,create_time,amount），如何给WHERE user_id=123 AND create_time>'2023-01-01'的查询建索引？

（敲黑板！）正确答案是(user_id,create_time)的联合索引！！！记住这个口诀：等值查询字段放前面，范围查询字段放后面。要是把create_time放前面，索引后半截就直接失效了！

2. 索引失效的七宗罪（实际开发高频坑）

• LIKE以%开头（name like '%张'）
• 对索引列做运算（where year(create_time)=2023）
• OR条件未全覆盖（where a=1 or b=2，若只有a有索引）
• 使用!=或<>操作符
• 类型转换（字符串字段传了数字）
• 最左前缀原则被破坏
• 索引列参与函数计算

（血泪教训）我见过最夸张的案例：某系统给手机号字段加了索引，结果因为存储时带上了+86前缀，查询时没统一格式，导致索引完全失效！

---

二、执行计划深度解析

EXPLAIN关键指标四天王

1. type列：从好到坏排序
   system > const > eq_ref > ref > range > index > ALL
   （看到ALL就要报警了！说明全表扫描了）

2. key_len计算：
   varchar(20) utf8mb4字段的索引长度计算？
   20*4 + 2 = 82（utf8mb4最大4字节，+2是长度标识）

3. rows字段：
   不是真实扫描行数！是估算值，但能反映查询成本

4. Extra列：

   • Using filesort：需要额外排序
   • Using temporary：用了临时表
   • Using index：覆盖索引（好事！）

---

三、慢查询优化实战套路

案例：分页查询优化

传统写法：

SELECT * FROM orders ORDER BY id LIMIT 1000000,10;

（要命了！）这种写法会先读取1000010行，然后扔掉前100万行！

优化方案：

SELECT * FROM orders 
WHERE id > (SELECT id FROM orders ORDER BY id LIMIT 1000000,1)
ORDER BY id LIMIT 10;

（原理揭秘）通过子查询先定位到起始位置ID，相当于书签的效果，执行速度提升100倍不是梦！

---

四、高级调优技巧

JOIN优化三板斧

1. 小表驱动大表：
   把数据量小的表作为驱动表（放在join左边）

2. 避免笛卡尔积：
   多个表join时一定要确保关联条件完备

3. 巧用STRAIGHT_JOIN：
   当优化器选错驱动表时，可以强制指定连接顺序

（实战技巧）曾经有个统计报表查询，通过调整join顺序，把执行时间从25秒降到了0.8秒！

---

五、事务与锁的相爱相杀

死锁排查四部曲

1. 执行SHOW ENGINE INNODB STATUS
2. 找到LATEST DETECTED DEADLOCK段落
3. 分析涉及的事务和锁
4. 查看information_schema.INNODB_LOCKS表

（避坑指南）批量更新操作一定要按固定顺序处理记录！！！这是避免死锁的黄金法则。

---

六、高频考点思维导图

SQL调优
├─ 索引优化
│  ├─ 最左前缀原则
│  ├─ 索引选择策略
│  └─ 索引失效场景
├─ 执行计划
│  ├─ EXPLAIN解读
│  └─ 关键指标分析
├─ 语句优化
│  ├─ 分页查询优化
│  ├─ JOIN优化
│  └─ 子查询改写
├─ 架构优化
│  ├─ 读写分离
│  └─ 分库分表策略
└─ 事务优化
   ├─ 隔离级别选择
   └─ 锁机制调优

七、面试反向攻略

当面试官问：“你做过哪些SQL优化案例？”
（加分回答模板）
“在XX项目中，我通过慢查询日志发现某个接口响应慢，分析EXPLAIN结果后发现…，通过调整索引/改写SQL/修改架构…，最终将查询时间从X秒降到Y秒，期间还解决了…的并发问题”

---

最后的大杀器

记住这个调优口诀：
一查执行计划，二看索引情况，三想业务场景，四测优化方案
（重要的事情说三遍！！！测试！测试！一定要测试优化效果！）

准备好这些知识点，下次面试官问你SQL调优时，你可以微笑着反问：“您想听索引优化、执行计划分析还是实战案例？” 😎