SQL执行计划是数据库优化核心，需聚焦Rows、Type/Join Type、Extra三指标识别性能瓶颈；验证索引是否生效要查最左前缀、数据类型一致性和key_length；执行计划仅反映预估，须结合EXPLAIN ANALYZE等工具看实际耗时。
SQL执行计划是数据库优化的核心依据，看懂它，才能找准性能瓶颈。重点不是记住每个字段含义，而是快速识别“哪里慢”“为什么慢”“怎么改”。
看执行计划，先盯三个关键指标
打开执行计划（如MySQL用 EXPLAIN，PostgreSQL用 EXPLAIN ANALYZE），第一眼聚焦：
-
Rows（或 estimated rows）：预估扫描行数。若远大于实际返回结果（比如查1条却扫10万行），说明过滤条件没走索引或索引失效；
-
Type / Join Type：MySQL里 ALL（全表扫描）、index（全索引扫描）风险高；ref、range、const 通常较健康；
-
Extra 列：出现 Using filesort（排序未走索引）、Using temporary（临时表）、Using join buffer（连接缓存）往往是性能雷区。
常见低效模式，一查就中
这些结构在执行计划里有明显信号，遇到直接优先排查：
-
WHERE 条件用了函数或计算：如
WHERE YEAR(create_time) = 2025 → 执行计划 type 常为 ALL，索引失效；改成 WHERE create_time BETWEEN '2025-01-01' AND '2025-12-31'；
-
LIKE 左模糊：如
WHERE name LIKE '%abc' → 无法使用索引；能改前缀匹配（'abc%'）就改，不能则考虑全文索引或倒排
；
-
SELECT * + 大表 JOIN：Extra 出现 Using temporary; Using filesort 很可能因没覆盖索引，导致回表+排序开销大；精简字段，给 JOIN 和 ORDER BY 字段建联合索引。
索引是否生效？三步快速验证
别只看“有没有索引”，要看“用没用对”：
- 确认查询条件字段是否在索引最左列（遵循最左前缀原则）；
- 检查索引列的数据类型和查询值是否一致（如字段是 VARCHAR，但传了数字不加引号，可能触发隐式转换，索引失效）；
- 用 EXPLAIN FORMAT=JSON（MySQL 5.7+）看
key_length 和 used_key_parts，确认索引用了几列、用到哪部分。
执行计划只是起点，不是终点
它告诉你“数据库打算怎么做”，但真实耗时还受数据分布、缓存状态、并发压力影响。建议：
- 配合 EXPLAIN ANALYZE（PostgreSQL）或 PROFILE（MySQL 8.0+）看实际执行时间与IO消耗；
- 对慢查询做 实际压测：加 LIMIT、改 WHERE 范围，观察执行计划变化；
- 定期用 slow query log + pt-query-digest 挖掘隐藏的“伪快查询”（单次不慢，但高频调用拖垮系统）。
基本上就这些。执行计划不是越复杂越高级，而是越清晰越有用——目标永远是：让数据库少干活、走捷径、不折腾。
；