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

标签： mysql oracle js json node ai 隐式类型转换 隐式转换 red