一条 SQL 很慢，你的排查与优化步骤是什么？
优化执行计划索引
考察意图
落地能力题。考察有条理的诊断路径，而不是上来就「加索引」。
回答框架
- 复现与量化：多久、多大、是否稳定。
- 看执行计划：扫描行数、是否索引、Join 方式。
- 改写与结构：谓词下推、避免选*、拆大查询。
- 基础设施：统计信息、参数、硬件瓶颈。
参考答案（口述版）
推荐口述顺序：
- 确认问题：慢在解析/执行/网络？数据量级？是否只高峰慢？
- EXPLAIN / EXPLAIN ANALYZE：看 type、rows、key、Extra（Using filesort/temporary）、实际耗时
- 常见招：
- 补合适索引或修正联合索引顺序
- 避免索引列函数；改写范围条件
- 减小选列、先过滤再 join；子查询改 JOIN
- 大 OFFSET 分页改寻键分页
- 避免隐式类型转换
- 仓场景：保证分区裁剪、减小 shuffle、预聚合
- 验证：优化前后对比，关注是否引入正确性风险
原则：先测量再动手；每次只改一处，保留回滚。
关键词
EXPLAIN分区剪枝谓词下推寻键分页
面试官可能的追问
追问 1：Using filesort 一定坏吗？
不一定，但大数据量时昂贵。若 ORDER BY 能与索引顺序一致，可消除或减轻。
常见踩坑
- 不看 explain 直接加索引
- 优化时改变了语义（尤其 NULL 与去重）
记忆锚点
先 EXPLAIN 定位，再针对性改；每次只改一处并验证。