sql查询性能差常因优化器基于错误统计信息生成低效执行计划，核心是基数估算误差导致连接方式、驱动表、索引选择错误；需通过执行计划对比预估与实际行数识别，并结合提高采样率、创建扩展统计、函数索引等精准修复。
SQL查询性能差，很多时候不是因为写法问题，而是优化器基于错误的统计信息做出了低效的执行计划。其中最典型的表现就是基数估算误差——优化器预测某一步骤返回的行数（cardinality）与实际严重偏离，导致选错连接方式、错误的驱动表、不该走索引却走了、该走索引却没走等。
为什么统计信息会不准
数据库（如 PostgreSQL、SQL Server、Oracle、MySQL 8.0+）默认通过采样或定期分析收集统计信息，但这些机制天然存在局限：
- 表数据频繁变更（大量 INSERT/UPDATE/DELETE）后未及时 ANALYZE / UPDATE STATISTICS
- 采样率过低（例如 PostgreSQL 默认采样约 100–300 行），对倾斜分布（如某值占 95%）完全无法反映
- 多列组合条件（WHERE a = ? AND b = ?）依赖列相关性统计，而多数数据库默认不收集多列统计，导致独立估算相乘，误差指数级放大
- 函数/表达式过滤（如 WHERE date_trunc('day', ts) = '2024-01-01'）无法命中列级统计，优化器只能按“未知选择率”粗略估算
如何识别基数估算误差
核心方法是查看执行计划中的 Rows Removed by Filter 和 Actual Rows vs. Planned Rows 对比：
- PostgreSQL：用
EXPLAIN (ANALYZE, BUFFERS)，重点关注每个节点的rows=xxx（预估）与actual rows=xxx（真实）比值是否超过 10 倍 - SQL Server：看 Execution Plan 中 tooltip 的 Estimated Number of Rows 和 Actual Number of Rows
- 注意“瀑布式误差放大”：上游节点估算偏差 5 倍，下游 JOIN 或嵌套循环可能放大到 50 倍以上，最终计划彻底失真
缓解和修复策略
不能只依赖“重新收集统计”，需结合场景精准干预：
- 对倾斜列（如 status、region）手动提高采样率：
ANALYZE table_name (col_name) WITH (STATISTICS_TARGET = 1000); - 为高频组合过滤列创建扩展统计（PostgreSQL 10+）：
CREATE STATISTICS s1 ON a, b FROM t;，再ANALYZE t; - 对表达式条件，可建函数索引并配合表达式统计（如
CREATE INDEX idx_ts_day ON t (date_trunc('day', ts));） - 临时应急：用
/*+ USE_NL(t1 t2) */（Oracle/MySQL）、OPTION (LOOP JOIN)（SQL Server）等提示强制计划，但属权宜之计
监控与预防建议
把统计质量纳入 DBA 日常巡检：
- 定期检查
pg_stats（PG）或sys.dm_db_stats_properties（SQL Server）中 last_updated 时间和 modification_counter（变更行数占比） - 对大表（>1M 行）且 DML 频繁的，设置自动 ANALYZE 触发阈值（如 PostgreSQL 的
autovacuum_analyze_scale_factor = 0.01） - 上线新查询前，在测试环境用真实数据量执行
EXPLAIN ANALYZE，重点核验关键谓词的基数估算
