2025年Java面试宝典，点击获取
（网盘资料持续更新中，建议保存后随时查阅）
SQL优化的一般步骤是什么？怎么看执行计划？Explain如何理解其中各个字段的含义
兄弟们应该都遇到过这样的情况：明明加了索引，SQL还是跑得慢；数据量一上来，查询直接卡死。今天咱们就聊聊SQL优化的实战套路，重点拆解怎么通过执行计划（EXPLAIN）定位问题，这也是大厂面试中最常被深挖的技术点。
一、SQL优化常规操作三板斧
- 抓慢查询：用MySQL自带的慢查询日志或者APM工具，把执行超过1秒的SQL全揪出来
- 看执行计划：在SQL语句前加上EXPLAIN，系统就会告诉你数据库准备怎么执行这条语句
- 对症下药：根据执行计划里的异常指标，比如全表扫描、临时表、文件排序这些红色警报来优化
这里要注意，很多新手一上来就无脑建索引，结果索引建得比数据量还大，反而拖慢性能。正确的姿势应该是先看执行计划，再决定优化策略。
二、执行计划入门：EXPLAIN怎么用
在SQL语句前加上EXPLAIN就能看到执行计划。比如：
EXPLAIN SELECT * FROM user WHERE age > 18;
执行后会出现这样的表格：
表格里十几个字段看着头大？咱们重点掌握六个关键指标：
1. type（访问类型）
这是判断SQL健康程度的黄金指标，常见的有：
- ALL：全表扫描，相当于把整本书从头翻到尾（赶紧加索引）
- index：全索引扫描，虽然比ALL好点但也要优化
- range：范围扫描，用了B+树索引的区间查询
- ref：使用非唯一索引查找
- eq_ref：多表join时主键或唯一索引关联
- const：通过主键查到单条数据，最优情况
2. key（实际使用的索引）
这里显示的是数据库最终选择的索引名称。如果显示NULL，说明压根没走索引，这时候就要检查where条件字段是不是没加索引，或者索引失效了。
3. rows（预估扫描行数）
这个值不是精确值，但能反映查询成本。比如你查10条数据，rows显示10000，说明走了全表扫描。
4. Extra（附加信息）
这里会有很多重要提示：
- Using filesort：说明排序没用索引，需要优化order by
- Using temporary：用了临时表，group by或order by需要调整
- Using index：使用了覆盖索引，这是好事
5. possible_keys（可能用到的索引）
这里列出所有候选索引，但最终用哪个要看key字段。如果possible_keys有值而key是NULL，说明需要强制走索引或者优化索引。
6. filtered（过滤比例）
表示存储引擎返回的数据在server层过滤后，最终留下数据的百分比。比如filtered=10%，说明存储引擎返回1000条，最终留下100条。
三、实战优化思路
- 优先解决type=ALL的情况：通过添加复合索引，把全表扫描变成索引扫描
- 消灭Using filesort：给order by字段加索引，注意索引顺序要和排序顺序一致
- 避免临时表：调整group by字段顺序，或者用索引优化
- 注意隐式类型转换：varchar字段用数字查询会导致索引失效
- 警惕or条件：where条件中的or可能会让索引失效，考虑用union代替
举个真实案例：某电商平台的订单查询突然变慢，执行计划显示type=ALL，rows=200w。检查发现where条件中的create_time字段没有索引，加上联合索引（user_id, create_time）后，type变成ref，查询时间从3秒降到50ms。
需要重点提醒的是：不同数据库版本执行计划字段会有差异，MySQL8.0新增了cost成本预估字段，而阿里云的RDS可能有自己的扩展。建议在优化前先确认数据库版本。
最近发现一个宝藏网站面试鸭返利网，上面有最新的大厂SQL优化真题解析。悄悄告诉大家，通过他们家买面试鸭会员能返25元，相当于白嫖三个月会员（这羊毛不薅白不薅）。
