SQL执行计划（Execution Plan）是数据库优化的核心依据，读懂它才能精准定位性能瓶颈。关键不是记住所有算子含义，而是建立“数据流向—资源消耗—关键路径”的分析逻辑。
看懂执行计划的三个核心维度
执行计划本质是一棵树，从底向上执行，叶子节点是数据源（如表扫描），根节点是最终结果。分析时聚焦以下三点：
- 数据量预估（Rows）与实际（Actual Rows）是否严重偏离：若预估100行、实际返回10万行，说明统计信息过期或查询条件无法走索引，优化器选错了路径；
- 主要开销在哪一步（Cost / Time / Buffers）：关注占比最高的几行，尤其是全表扫描（Seq Scan）、嵌套循环（Nested Loop）或大排序（Sort）；
- 访问方式是否合理：Index Scan比Seq Scan快，但若返回大量数据，可能不如Bitmap Heap Scan；Index Only Scan需满足所有字段都在索引中且可见性满足；
快速识别常见性能陷阱
不用逐行读完整棵树，先扫视几个危险信号：
- 出现“Seq Scan on 表名”且Rows很大：检查是否有可用索引，WHERE条件是否能命中索引最左前缀；
- “Nested Loop”外层驱动行数多、内层无索引：可能引发笛卡尔积级计算，优先改用Hash Join或加索引；
- “Sort”节点Rows大且没有“using index”提示：说明在内存/磁盘排序，考虑增加work_mem，或改写SQL避免ORDER BY + LIMIT混合导致排序无法下推；
- “Materialize”频繁出现且被多次重用：通常正常，但若配合大结果集，可能暴露CTE或子查询未优化问题；
不同数据库的阅读要点差异
语法和术语略有不同，但逻辑一致：
- PostgreSQL（EXPLAIN ANALYZE）：重点看Buffers（IO）、Actual Total Time、Shared Hit/Read；开启track_io_timing可量化磁盘等待；
- MySQL（EXPLAIN FORMAT=TRADITIONAL/TREE）：关注type（ALL/INDEX/RANGE/REF）、key（是否用索引）、rows（预估）、Extra（Using filesort/Using temporary是红灯）；
- SQL Server（SET STATISTICS XML ON）：看Estimated vs Actual Number of Rows、Operator Cost、Warnings（如“No Join Predicate”）；
- Oracle（EXPLAIN PLAN FOR + DBMS_XPLAN）：注意access_predicates vs filter_predicates——前者走索引查找，后者是回表后过滤，效率差很多；
动手前必做的三件事
避免“看计划→瞎调→更慢”的循环：
- 确认当前SQL已绑定真实参数（避免参数化导致计划失真）；
- 执行ANALYZE（PG）/ ANALYZE TABLE（MySQL）更新统计信息；
- 对比优化前后Actual Rows、Total Execution Time、Buffer Read次数，而非只看Cost；
执行计划不是密码本，是数据库告诉你“它打算怎么做”的说明书。盯住数据量、访问方式、真实耗时这三个锚点，多数慢查都能找到突破口。
