SQL执行计划如何分析_高频场景实例讲解便于理解使用【指导】

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（实际） 两列：

Icons8 Background Remover

Icons8出品的免费图片背景移除工具

31

查看详情

• 若预估 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% 的慢查优化就有方向了。

以上就是SQL执行计划如何分析_高频场景实例讲解便于理解使用【指导】的详细内容，更多请关注php中文网其它相关文章！