行数估算和成本计算是sql执行计划优化的核心依据，估算不准会导致索引误选、连接算法错误等问题；常见原因包括统计信息陈旧、函数谓词、缺失联合统计及隐式转换；可通过对比实际与期望行数识别偏差；优化需刷新统计、补充直方图、重写谓词或使用优化器提示。
SQL执行计划中的行数估算（Cardinality Estimation）和成本计算（Cost Calculation）是查询性能优化的核心依据。估算不准，优化就容易南辕北辙——比如本该走索引的走了全表扫描，或本该哈希连接的用了嵌套循环。
行数估算不准的常见原因
数据库优化器依赖统计信息推算中间结果集大小，一旦统计过期、列值分布倾斜、多列关联复杂，估算就会严重失真：
- 统计信息陈旧：表数据大量增删改后未及时 ANALYZE（PostgreSQL）或 UPDATE STATISTICS（SQL Server）或 DBMS_STATS.GATHER_TABLE_STATS（Oracle）
- 谓词含函数或表达式：WHERE UPPER(name) = 'TOM'、WHERE date_col + INTERVAL '1 day' > SYSDATE 等，导致无法使用列统计直方图
- 多条件组合无联合统计：WHERE city = 'Shanghai' AND gender = 'F'，若未收集 (city, gender) 联合直方图，优化器常按独立概率相乘估算，低估或高估严重
- 隐式类型转换：如字符串字段与数字比较（status = 1），触发函数索引失效且破坏统计匹配
从执行计划看估算偏差的方法
对比“Rows (Actual)”与“Rows (Expected)”两列（不同数据库叫法略有差异，如 PostgreSQL 的 actual rows vs rows，Oracle 的 A-Rows vs E-Rows）：
- 实际行数比估算大10倍以上 → 可能低估，导致选错连接算法（如该用哈希连接却选了嵌套循环）或分配内存不足
- 实际为0但估算很大 → 可能存在过滤性极强的谓词未被识别（如分区裁剪失败、函数索引未命中）
- 某节点估算骤降但实际不变 → 检查该步是否丢失了统计传播（例如 GROUP BY 后未更新基数，或窗口函数未建模）
针对性优化策略
不靠猜，靠验证；不盲目加索引，先稳住估算：
- 强制刷新关键统计：对高频变更的大表，设置定时任务收集统计（如 PostgreSQL 中 ANALYZE table_name (col_a, col_b); 指定列+采样率）
- 补充联合统计或直方图：在过滤组合频繁的列上创建多列统计（PostgreSQL 10+ 支持 CREATE STATISTICS；Oracle 支持 METHOD_OPT=>'FOR COLUMNS (a,b) SIZE 254'）
- 重写难估算的条件：把 UPPER(name) = 'TOM' 改为 name ILIKE 'tom'（启用 text_pattern_ops 或 citext 类型），或增加函数索引并确保查询能命中
- 用 /*+ OPT_ESTIMATE */ 或 /*+ CARDINALITY */ 提示（Oracle/SQL Server）临时矫正，仅用于紧急定位，不可长期依赖
成本不是绝对值，而是相对标尺
执行计划底部的 Cost 是优化器内部归一化数值，单位无物理意义。重点看各分支成本占比和驱动路径选择逻辑：
- 若 Index Scan 成本远低于 Seq Scan，但优化器仍选后者 → 检查是否禁用了索引（enable_indexscan=off）、索引字段有 IS NULL / NOT IN 等低效模式
- Hash Join 总成本显著高于 Nested Loop → 可能因右表估算过大，导致哈希表内存超限而退化为 Grace Hash 或磁盘拼接
- Sort 操作成本突增 → 关注是否缺失排序字段索引，或 work_mem 设置过小引发外排（external sort）
