SQL执行计划需结合成本模型识别高成本操作并优化：关注Actual Rows与Rows偏差、单步Cost占比超30%、Seq Scan+Filter等问题，通过更新统计信息、建合适索引、规避高开销操作来降本，并用EXPLAIN (ANALYZE, BUFFERS)验证效果。

SQL执行计划不是“看懂就行”，而是要结合成本模型判断哪一步真正拖慢了查询，再针对性优化。关键在识别高成本操作、理解代价来源、验证改动效果。

看清执行计划里的真实成本

数据库（如PostgreSQL、SQL Server、Oracle）生成的执行计划中，“Cost”字段是基于统计信息估算的相对开销，不是毫秒数，但能反映各节点的资源消耗权重。重点关注：

• 实际行数（Actual Rows）远大于估算行数（Rows）：说明统计信息过期或查询条件选择率不准，优化器选错了连接方式或访问路径；
• 单步Cost占比超过总Cost的30%：比如一个Nested Loop Join占了70%总成本，就要检查是否缺少索引、驱动表顺序是否合理、连接字段是否有类型隐式转换；
• 出现Seq Scan + Filter大量行：意味着本该走索引却走了全表扫描，常见于WHERE条件未覆盖索引前导列、函数包裹字段（如WHERE UPPER(name) = 'ABC'）、或数据倾斜严重导致索引失效。

从成本模型反推优化路径

主流优化器（如PostgreSQL的COST-based Optimizer）的成本公式大致为：
Total Cost ≈ Startup Cost + (Per-Row Cost × Estimated Rows)
所以降低总成本，无非三条路：

• 减少估算行数：更新统计信息（ANALYZE table_name），或重写条件让选择率更可估（例如避免LIKE '%abc'，改用全文检索或倒排索引）；
• 压低单行处理代价：给高频过滤字段建索引，尤其复合索引要遵循“等值→范围→排序”顺序；对JOIN字段确保类型一致、有索引、且基数分布合理；
• 规避高固定开销操作：比如Sort节点若出现在大结果集上，考虑加ORDER BY字段索引；HashAggregate若输入行数爆炸，先用WHERE或子查询收缩数据集再聚合。

验证优化是否真的降了成本

别只看“执行快了”，要对比执行计划的Cost变化和实际性能指标：

• 用EXPLAIN (ANALYZE, BUFFERS)获取真实耗时、IO次数、内存使用，确认高Cost步骤的Actual Time是否显著下降；
• 对比优化前后“Shared Hit Blocks”与“Shared Read Blocks”，IO减少通常比CPU节省更有效；
• 对复杂查询，分段加/*+ MATERIALIZE */（Oracle）或CTE加MATERIALIZED（PostgreSQL 12+）强制物化中间结果，观察Cost是否从指数级降为线性。

几个易被忽略但影响成本的关键细节

• JOIN顺序不是SQL写的顺序：优化器会重排，但可通过STRAIGHT_JOIN（MySQL）或LEADING hint（Oracle）干预——仅在确定驱动表更小时才用；
• 函数索引必须完全匹配调用形式：建了INDEX ON users ((lower(email)))，就必须写WHERE lower(email) = 'a@b.com'，写WHERE email = 'A@B.COM'仍无法使用；
• 分区表不是自动优化：没在WHERE中带上分区键，优化器可能无法Pruning，导致扫描所有分区——此时Cost虚高且实际慢。