SQL执行计划深度解读，根治慢查询
你是否曾遭遇这样的困境：一条SQL从秒级响应突然跌至分钟级，翻出慢查询日志锁定语句后，却完全摸不着头绪。盲目加索引、换写法毫无效果，最后只能重启数据库碰运气。
这种“玄学优化”之所以屡试不爽，根源在于缺少一份数据库的“诊断报告”——它就是执行计划。
执行计划是数据库在执行SQL前生成的“作战蓝图”：清晰展示数据访问路径、所用索引、预估扫描行数以及各类附加操作。学会解读执行计划，优化就从猜测变为洞察，告别盲目试错。
接下来拆解执行计划中最核心的五个字段，读懂它们即可在第一时间定位慢查询的病根。
type：访问方式，性能的“信号灯”
type指明数据库访问表数据的方式。性能从优到劣排序：system > const > eq_ref > ref > range > index > ALL。
类比驾驶效率：
const：专属快车道，通过主键或唯一索引直接命中唯一行。ref：城市主干道，普通索引命中多行，速度尚可。range：主干道遇红绿灯，索引范围扫描（如BETWEEN、>、<），走走停停。index：辅路慢行，全索引扫描，虽比全表快但仍有优化空间。ALL：全路拥堵，全表扫描，必须立即优化。
一个硬性判断标准：看到ALL或index，索引设计几乎必然存在缺陷或索引失效。
key_len：复合索引的实际使用深度
对于复合索引(a,b,c)，key_len显示实际使用了多少列。例如INT占4字节，DATE占3字节，VARCHAR按字符集计算（utf8mb4每字符4字节，另加2字节长度标识）。若索引定义总长50字节但key_len仅4，说明只用了首列。
不必死记公式，只需对比索引定义与key_len数值，即可判断查询条件是否满足最左前缀原则。若key_len偏小，往往因条件未覆盖所有前缀列，或跳过了中间列。
rows：估算扫描行数
rows是优化器基于统计信息估算的需要扫描的行数。虽非精确值，但其量级直接反映查询成本。
判断标准：rows越大，性能越差。若rows接近全表行数却仍在走索引，说明索引选择性极低（例如仅对性别字段建索引），优化器可能已误判。
filtered：索引筛选后的剩余比例
filtered表示存储引擎返回的行中，满足剩余WHERE条件的百分比。100%为最佳，意味着索引已精准定位，无需额外过滤；10%则索引仅过滤掉90%，回表后仍需大量筛选，通常因为索引列选择性差，或查询条件包含非索引字段。
诊断时注意：filtered偏低时，应考虑扩展索引将过滤字段纳入，或调整索引顺序。
Extra：执行中的“附加操作”
Extra列展示数据库在执行过程中需要做的额外操作，部分为优选，部分为性能瓶颈。
Using index：覆盖索引，无需回表 ✅Using index condition：索引条件下推，提前过滤，减少回表 ✅Using where：需回表后过滤 ⚠️Using temporary：使用临时表，常见于GROUP BY未走索引 ❌Using filesort：文件排序，常见于ORDER BY未走索引 ❌Using join buffer：JOIN未走索引 ❌
这些标记直接指向优化方向：出现temporary则为GROUP BY列建索引；出现filesort则为ORDER BY列建索引；出现join buffer则检查连接条件是否存在索引。
为更直观理解这些字段如何协同，来看一个精简的诊断流程。
假设有一条慢查询，执行EXPLAIN后得到输出。无需逐行细读，按顺序自问三个问题：
第一问：type是什么？
若为ALL或index，根因是访问方式过于原始。优先检查WHERE条件涉及的列是否有索引，以及是否存在隐式类型转换、函数包裹等导致索引失效的情况。
第二问：key_len是否合理？
对照已创建的复合索引定义，检查key_len是否覆盖了期望列数。若明显偏小，说明查询条件未用到索引前缀，需调整索引列顺序或补全查询条件。
第三问：Extra里是否有temporary或filesort？
若有，说明GROUP BY或ORDER BY未走索引。检查这些列是否在索引中，以及索引顺序是否匹配排序要求。
走完这三步，80%的慢查询病因即可锁定。剩余20%往往与数据分布不均、统计信息过时有关，此时可执行ANALYZE TABLE更新统计，或在测试环境用EXPLAIN ANALYZE获取真实执行数据。
从执行计划到优化动作，核心逻辑不是堆砌索引，而是先读懂数据库的反馈，再有针对性地调整。type提示“怎么查”，key_len提示“用了几列”，rows与filtered量化“代价多大”，Extra揭示“额外负担”。将五个字段串联起来，几十秒内即可判断一条SQL的健康度，并快速锁定问题。
下次遇到慢查询，别再盲目加索引。先跑一遍EXPLAIN，让数据库告诉你它需要什么。
