SQL 执行计划选择偏差源于统计信息失真、代价模型参数脱离实际硬件、谓词组合基数估算失效及隐式类型转换四类可追溯原因，需分层定位修复。
SQL 执行计划选择偏差，本质是优化器对操作代价的估算与实际运行成本严重不符。这种误判不是随机错误，而是源于统计信息失真、模型假设僵化或数据分布异常等可追溯原因。
统计信息过期或粒度不足
优化器依赖表和索引的行数、数据分布（如直方图）、空值比例等统计信息估算 I / O 和 CPU 开销。若长期未更新统计信息，或采样率过低导致直方图无法反映真实偏态分布（例如某字段 95% 值为 ’ACTIVE’，其余分散在上百种状态），优化器会低估索引查找的重复回表次数，错误选择索引扫描而非全表扫描。
- 定期在业务低峰期执行 ANALYZE TABLE（PostgreSQL）或 UPDATE STATISTICS（SQL Server）
- 对倾斜字段（如 状态码 、地域 编码）启用高频值直方图（如 MySQL 的
PERSISTENT FOR ALL，Oracle 的FOR COLUMNS SIZE AUTO） - 避免在大表上使用默认采样率；对亿级表，手动指定 10% 以上采样比例
代价模型参数脱离实际硬件
优化器内置的代价常量（如一次随机 I / O 等价于 4 次顺序 I /O、CPU 运算单位成本）通常基于旧硬件设定。当数据库运行在 NVMe SSD 集群或内存超配环境时，随机读延迟已降至微秒级，但优化器仍按毫秒级估算，导致它高估索引范围扫描代价，转而选择看似“更省 I /O”的哈希连接或物化临时表。
- 查看当前代价参数：PostgreSQL 用
SHOW random_page_cost，SQL Server 查sys.dm_exec_query_optimizer_info - 在 SSD 环境将
random_page_cost从默认 4.0 调至 1.0–1.5；内存充足时降低cpu_tuple_cost - 不建议全局修改，可用
SET LOCAL在会话级动态调整并验证执行计划变化
谓词组合导致基数估算失效
单个条件（如 status = 'PAID'）的行数估算可能准确，但多个条件 AND/OR 叠加后，优化器默认按独立事件计算（cardinality = N × selectivity₁ × selectivity₂），忽略字段间真实相关性。例如country = 'CN' AND city IN ('BJ', 'SH', 'GZ') 在现实中高度相关，但优化器误判为极低基数，引发嵌套循环连接误选。
- 启用多列统计信息：PostgreSQL 12+ 支持
CREATE STATISTICS定义相关列组 - 对固定组合谓词，用扩展统计（Extended Statistics）捕获联合分布，替代默认独立假设
- 临时方案：用
/*+ USE_NL(t1 t2) */等提示强制连接方式，但需同步补充统计修复根因
隐式类型转换 破坏索引选择
当查询字段为 VARCHAR，而 WHERE 条件传入整数（如WHERE user_id = 123），数据库自动转为WHERE CAST(user_id AS INTEGER) = 123。该表达式无法走索引，但优化器在估算阶段可能忽略转换开销，仍按“索引等值查找”计算低成本，最终生成带索引扫描却实际执行全索引遍历的计划。
- 检查执行计划中是否出现
Index Scan using xxx on t (cost=……)但Actual Rows远高于Rows Removed by Filter - 统一应用层传参类型，避免字符串字段用数字比较
- 在关键字段上建立函数索引（如
CREATE INDEX idx_uid_int ON users ((user_id::bigint))）作为兜底
代价误判不是黑箱故障，而是统计、模型、数据三者错配的结果。定位时优先核对统计信息新鲜度与分布质量，再验证硬件参数适配性，最后排查谓词逻辑和类型行为。修复后务必用真实负载验证，避免理论最优变成实际更差。
