sql执行计划优化需聚焦四点：访问方式（如type为ALL需建索引）、连接顺序（驱动表应为小结果集）、预估与实际行数偏差（反映统计信息或隐式转换问题）、Extra提示（如using filesort需添加联合索引）。
SQL执行计划是数据库优化的核心依据，看懂它，才能精准定位慢查询的瓶颈。关键不是背术语，而是抓住几个核心指标：访问方式、连接顺序、数据量预估、实际开销分布。
看懂“访问类型”——是走索引还是全表扫描？
在执行计划中重点找 type（mysql）或 node Type（postgresql/oracle）字段：
- const / eq_ref：单行精确匹配，性能最好，比如主键或唯一索引等值查询
- ref / index_scan：走了索引但可能返回多行，常见于普通索引等值查询
- range：索引范围扫描，如
WHERE age BETWEEN 25 AND 30，效率尚可 - ALL / Seq Scan：全表扫描，数据量一大就明显变慢，优先排查是否缺索引或索引失效
⚠️ 注意：即使写了 WHERE status = 'active'，如果该字段选择性极低（比如95%都是 active），优化器也可能放弃索引走全表扫描——这时加索引未必有效，要考虑业务逻辑或配合其他字段建联合索引。
识别“连接顺序与方式”——谁驱动谁？怎么连？
多表 JOIN 时，执行计划会显示表的访问顺序和连接算法：
- MySQL 常见：Index Nested-Loop Join（NLJ）（小表驱动大表+索引）、Hash Join（8.0.18+，适合等值连接大表）
- PostgreSQL 常见：Nested Loop（小结果集驱动）、Merge Join（两表都已排序）、Hash Join（内存足够时最快）
✅ 实用判断法：看最外层驱动表（第一行或缩进最浅的表）是否是小结果集。如果 orders 表被当作驱动表，而它有千万行，但 order_items 只有几万行，那很可能顺序反了——可通过 STRaiGHT_JOIN 或重写子查询强制调整。
对比“预估 vs 实际行数”——判断统计信息是否过期
执行计划里常有 rows（预估） 和 filtered / actual rows（实际） 两列：
- 若预估 100 行，实际返回 10 万行 → 统计信息不准，需
ANALYZE table（MySQL）或ANALYZE（PG）更新 - 若预估 10 万，实际 100 → 可能存在隐式类型转换或函数包裹字段（如
WHERE date(create_time) = '2024-01-01'），导致索引失效且基数估算失真
? 小技巧：在 MySQL 中启用 EXPLAIN format=jsON，查看 execution_plan 下的 rows_examined_per_scan 和 rows_produced_per_join，比传统格式更能反映中间过程。
关注“Extra 列”——那些藏在角落的关键提示
MySQL 的 Extra 字段是“问题速查表”，高频项含义直给：
- Using filesort：需要额外排序，没走索引排序；检查
ORDER BY字段是否在索引最左前缀中 - Using temporary：用了临时表，常见于 GROUP BY + 非索引字段、DISTINCT + 无索引、union 等；考虑添加覆盖索引或改写逻辑
- Using index condition：启用了 ICP（索引条件下推），是好事，说明部分 WHERE 条件下推到存储引擎层过滤
- Using where; Using index：覆盖索引 + 索引过滤，理想状态
? 示例：执行 EXPLAIN select id, name FROM users WHERE city = 'Beijing' ORDER BY create_time DESC; 若 Extra 出现 Using filesort，而 (city, create_time) 没建联合索引，就该补上——让排序也走索引。
基本上就这些。执行计划不是一次看懂的文档，而是对照 SQL 改一行、看一变的调试地图。抓准访问类型、连接逻辑、行数偏差、Extra 提示这四点，80% 的慢查优化就有方向了。