上周接手一个 BI 系统的维护任务，运维同学反馈说“每月 1 号凌晨生成的财务报表偶尔会超时，但手动查数据很快”。起初我以为是数据量大或者 SQL 写得烂，盯着执行计划看了半天也没发现明显的索引缺失。直到复现了那个特定时间点的问题，我才意识到这是 PostgreSQL 中一个容易被初级开发者忽略的“隐形杀手”——统计信息滞后。这篇文章就从这次线上故障出发，聊聊如何定位和解决这类问题。
Bug 复现：为什么手动查快，定时任务慢？
这个 BI 系统的核心表是 order_detail（订单明细表），每天新增约 50 万条记录。报错发生在每月初，当报表查询过去三个月的数据时。
我首先尝试在业务高峰期手动执行那条复杂的聚合 SQL，结果只用了 300ms。但在模拟凌晨低负载环境（通过 pg_sleep 或控制并发）时，同样的查询耗时飙升至 12s。
差异在哪里？关键在于数据分布的变化。月初是新一个月订单开始涌入的时候，而统计报表查询的是历史数据。如果 PostgreSQL 的优化器认为“大多数数据集中在最近几天”，它可能会选择一个基于时间范围的全表扫描或者错误的索引路径，而不是我们期望的高效区间扫描。
这里有一个常见的误区：很多初学者认为只要加了索引就万事大吉。其实，索引选择依赖于优化器对数据分布的预估。如果预估错误（比如低估了旧数据的数量），优化器就可能做出糟糕的决定。
-- 模拟故障场景的查询：统计过去3个月各渠道订单总额
SELECT
channel_id,
SUM(amount) as total_amount,
COUNT(*) as order_count
FROM
order_detail
WHERE
create_time >= NOW() - INTERVAL '3 months'
GROUP BY
channel_id;
这条 SQL 本身很标准，但如果在 create_time 上只有普通 B-Tree Index，且统计信息显示该列的数据极度倾斜（例如最近一周占了总数据的 90%），优化器可能会误判范围扫描的成本过高而转向其他策略。虽然在这个例子中全表扫描可能不是最优解，但在某些涉及多表 Join 的场景下这种误判会导致灾难性的内存溢出或锁等待。
根因定位：autovacuum runner 没跟上吗？
定位到是“估算行数”与“实际行数”偏差大后，下一步就是检查统计信息是否最新。PostgreSQL使用 pg_stat_user_tables视图来监控表的自动清理（Autovacuum）状态和最后一次分析（Analyze）的时间戳。
SELECT
relname,
last_vacuum,
last_analyze,
n_live_tup, -- Optimizer estimate of live rows
n_dead_tup -- Dead rows waiting for vacuum
FROM
pg_stat_user_tables
WHERE
relname = 'order_detail';
查看结果时发现一个奇怪的现象：last_analyze的时间竟然是三天前！虽然 PostgreSQL会自动触发 Analyze操作当死元组比例超过阈值（默认为5%）时，但如果表的写入模式是“大批量插入+少量更新”，或者 Autovacuum worker进程被长时间阻塞在其他长事务上（哪怕是不相关的长事务），Analyze可能被延迟执行导致统计信息严重过时。更隐蔽的情况是如果该表刚进行过大规模的 DELETE操作而没有随之进行 ANALYZE导致估算值远高于实际值让优化器以为需要读取大量空槽位从而选择了错误的计划路径尽管这种情况较少见但在高删除率的业务中确实存在风险此外我们还检查了`autovacuum_naptime参数发现它被配置为60s这对于高吞吐量的写入场景来说可能略显保守尤其是在月底结算期间当写入峰值出现时系统忙于处理VACUUM而推迟了ANALYZE的执行这直接导致了月初报表生成时的性能抖动我们需要在紧急修复后立即调整这些参数并考虑对关键维度表启用更激进的自动分析策略以确保元数据的时效性不过在这之前我们先要验证一下强制刷新统计信息后的效果接下来我们将执行强制ANALYZE命令看看能否立即恢复正常的查询性能这也为我们后续制定长期的维护方案提供了直接的依据和数据支持让我们看看具体的操作步骤吧首先我们在测试环境复现这个问题然后通过手动执行命令来观察执行计划的改变这个过程非常直观也能帮助团队里的其他成员理解为什么看似相同的SQL语句在不同时间点会有如此巨大的性能差异这种差异往往源于数据库内部状态的微妙变化而不是代码逻辑本身的错误这也是调试高性能系统时需要具备的一种思维方式即不仅要看代码还要看数据库的运行状态和资源分配情况好的让我们回到正题现在让我们来手动执行一下这个命令并对比前后的执行情况看看会发生什么神奇的变化呢
本文参考文献：
http://www.ycanbao.com/juejin-a1rf7yot.html
