搞 PostgreSQL 跑久了，总会遇到一个让人摸不着头脑的问题：一条本来跑得飞快的 SQL，某天突然慢到让人怀疑人生；或者一张表明明不大，关联查询却选了嵌套循环，把十几万行的表当成了几千行来算。这种问题十有八九出在优化器对数据行数的“预判”上，而预判的根基就是统计信息。前段时间我把这个问题抛给 DeepSeek，让它基于 PostgreSQL 官方文档和常见性能案例帮我梳理了一套逻辑，再结合自己线上环境里踩过的坑，整理成下面这份相对完整的分析。适合刚接触性能调优的开发同学，也适合已经在维护数据库但偶尔被优化器“暗算”的 DBA。
统计信息不是一个玄学概念，它是优化器用来估算数据分布、决定连接顺序和索引选择的核心依据。搞懂了它，你看执行计划时的很多“为啥这么选”的问题都会迎刃而解。
1. 统计信息到底是什么：优化器手里的“数据地图”
1.1 一张表里的数据分布，远比想象中复杂
很多人最开始听到“统计信息”时，以为它只是记录了一张表有多少行。确实，行数是最基础的指标，但优化器需要的远不止这个。它还需要知道某个字段的取值有多少种、是否有空值、空值占比多高、最大值最小值在哪、哪个值出现得最频繁、数据在物理存储上是不是和索引顺序高度相关。只有把这些信息都摸清了，优化器才能对一条 WHERE 条件做出合理的“选择性”判断。
举个例子，一张用户表里有性别字段，如果绝大多数行都是“男”，那你在 WHERE 条件里写gender = '男'，优化器会认为过滤掉的行很少，可能就不愿意用它走索引。相反，如果这个字段只有极少数的“女”，那过滤效果很好，索引命中率自然高。统计信息的作用就是在不确定具体查询值的情况下，给出一个概率性的判断。
1.2 统计信息存在哪：pg_statistic 与 pg_stats
PostgreSQL 把统计信息存放在两个层面。底层是pg_statistic系统目录表，里面按列存储着采样出来的明细数据，但普通用户读不了。日常我们查询的是视图pg_stats，它把复杂的数据抽象成了可读的指标。需要特别注意的是，pg_stats会对普通用户隐藏某些字段权限，如果是跨库或者只读账号，可能拿不到完整信息，排查时要注意权限问题。
1.3 几个你必须读得懂的统计信息指标
打开pg_stats，你会看到ndistinct、n_distinct、most_common_vals、most_common_freqs、histogram_bounds、correlation这些字段。别看它们名字绕口，每一个都直接决定执行计划的质量。
n_distinct：估算的字段去重值数量。如果是负数，表示去重数量占行数的比例。这个值不准，会对 GROUP BY、DISTINCT 和 Hash Join 的估算产生连锁影响。most_common_vals / most_common_freqs：MVC（最常见值）列表及其对应的出现频率。等值查询如果命中这个列表，优化器就能精确估算返回行数。histogram_bounds：直方图边界。用于非最频繁值区间的等值查询和范围查询估算。correlation：物理行排序和逻辑列值排序的相关性，范围在 -1 到 1 之间。绝对值越接近 1，说明数据在磁盘上越有序。这个值对索引扫描的估算影响非常大，因为随机 IO 和顺序 IO 的成本差很多。
只看这些字段名还不够。真正要理解的是，这些指标之间会互相影响。比如n_distinct偏差导致 Hash Join 时选错哈希策略，MVC 覆盖不到的值走直方图估算，直方图又可能因为数据空洞产生偏差。优化器并不是单纯拿一个值做判断，而是把这些指标拼在一起形成一张完整的数据画像。
提示：
pg_stats中的统计信息是采样估算的，不是精确值，因此肉眼看到“合理”不代表真实分布合理。特别是在小表上，采样比例高估算比较准；大表采样率低，偏差就可能非常夸张。
2. 统计信息如何左右执行计划
2.1 优化器的成本模型：一条 SQL 如何被翻译成“价格标签”
PostgreSQL 的优化器本质是个“价格计算器”。它把扫描一条顺序记录的成本、随机读取一个页面的成本、处理一行的 CPU 成本、比较一个表达式要消耗的资源，全部累加成一组数字。在计算这些成本前，它必须先估出两个关键变量：每个步骤要处理多少行、每个步骤要从磁盘读多少数据页。
这两个变量的起点，就是表上的reltuples（表的估算行数）和列上的n_distinct、histogram_bounds。如果这些数字失真，后续所有的成本估算都会跟着失真，最终选出的执行计划自然不是最优的。
一个典型的例子：两表关联时，如果优化器错误地认为 A 表经过过滤后只剩 10 行，而实际上有 10000 行，它就会选择嵌套循环连接，并对 10000 行数据执行 10000 次索引查找。正常情况下这是灾难级别的性能问题。
2.2 统计信息误差如何在执行计划里被放大
误差并不仅仅是行数差几倍这么简单，它会在多表连接中被逐层放大。比如三表关联时，第一层连接估算误差是 2 倍，第二层可能就变成 8 倍，到第三层可能变成 64 倍。原因是优化器会把前一个步骤估算出来的输出行数作为下一个步骤的输入，误差会以乘数方式叠加。这也是为什么有时候你看到EXPLAIN里某个节点的估算行数和实际行数差了 100 倍，而最终结果只是慢了一点点。如果差的倍数太大，执行计划可能会彻底选错连接算法和连接顺序。
2.3 统计信息与索引：依赖还是博弈？
很多人误以为建了索引，查询就一定走索引。实际上优化器会选择代价更低的访问方式。分布式表查询时，优化器需要估算“符合条件的数据在表中的分布比例”。如果统计数据认为需要返回的数据占了全表 30% 以上，顺序扫描的代价可能低于索引扫描。于是你看到的就是“明明有索引，却选择了全表扫”。很多时候这不是索引失效，而是统计信息告诉优化器“用索引更贵”。
correlation这个指标在这里尤其重要。当列的物理分布顺序和索引顺序高度相关，优化器认为索引扫描会大量读取相邻页面，代价低，因此倾向于使用索引。反之，如果数据是随机分布，用索引意味着频繁随机读，代价飙升。这解释了为什么有时候对一张表的某一列做VACUUM ANALYZE后，执行计划突然从全表扫描变成了索引扫描，因为分析过程中重新计算了相关性，把底层的成本判断改变了。
3. 性能滑坡现场：怎么判断就是统计信息惹的祸
3.1 症状一：同样的 SQL，有时快有时慢
这类问题最让人抓狂。一条 SQL 在业务低峰期跑得很快，一到高峰期就慢得离谱。一个很常见的触发场景是：业务表经常被大量插入和删除，autovacuum 的触发频率跟不上下游流量，统计信息里的行数停留在之前的状态。白天高峰期产生的估算偏差到了夜间批量任务时被放大，于是夜里报表查询反而比白天还慢。
遇到这种情况，不要急着改 SQL，先手动执行一次ANALYZE，看看查询有没有改善。如果ANALYZE之后速度恢复正常，那基本可以锁定是统计信息过期的问题。注意，手动ANALYZE后可能会产生新的执行计划，短期速度恢复并不代表长期稳定，你需要从机制上调整自动分析的频率。
3.2 症状二：明明刚建了索引，查询却走全表扫描
这种场景通常出现在新索引刚创建、但还没有运行过ANALYZE的时候。PostgreSQL 的 autovacuum 因为各种原因未必会立刻分析这张表。你再怎么刷新执行计划缓存也无济于事，因为优化器手里没有索引对应列的统计信息，无法估算它的选择率，只能退回到顺序扫描。
我在实际项目中还见到一种更隐蔽的情况：建索引之后马上ANALYZE了，但ANALYZE的采样范围没有覆盖到 where 条件中最关键的值。比如线上环境某个字段的高频值恰好没有被采样到，那么优化器会把这些值放进一个普通的直方图估算里，算出来的行数偏差很大。这时候的索引看起来是“失效”的，但本质上还是统计信息精度不足。
3.3 标准排查流程：EXPLAIN、pg_stats、真实行数三方对比
判断是不是统计信息问题时，我一般会做三步操作。第一步，跑EXPLAIN (ANALYZE, BUFFERS)查看“预估行数”和“实际行数”，观察偏差倍数。第二步，到pg_stats里检查相关列的most_common_vals和histogram_bounds，看看查询中使用的常量值是否落在高频列表或直方图区间。第三步，用COUNT(*)查一下满足条件的真实行数，和统计信息对比。
这三步做下来，基本能定位到是“行数估算错了”“该值在直方图里没有合理记录”还是“连接顺序估算失败”。如果偏差超过 5 倍且执行计划因此选错，那就要考虑调整采样率或更新统计信息。
注意：
EXPLAIN (ANALYZE)会真实执行 SQL，如果是严重耗时的线上查询，请加上TIMEOUT或者在从库/测试环境先操作。不要为了排查问题把生产库拖垮。
4. 统计信息的保质期：收集机制与调优手段
4.1 ANALYZE 和 autovacuum 到底在干嘛
ANALYZE命令的作用是对表数据进行采样，并生成统计信息存入目录表。autovacuum 是一个后台守护进程，它除了清理死元组外，还会在达到阈值时触发ANALYZE。但 autovacuum 的触发条件是“数据被修改的行数达到一定比例”，这个默认阈值通常设定为表行数的 10% 左右。对于频繁更新小部分数据的场景（比如 10 万行的表，每分钟更新 500 行），autovacuum 可能要很长一段时间才会触发一次ANALYZE，这就是统计信息过期的根源。
要改变这种情况，可以调整autovacuum_analyze_threshold和autovacuum_analyze_scale_factor。阈值配合缩放因子，公式是阈值 + 缩放因子 × 当前表行数。比如把阈值设成 1000，缩放因子设成 0.05，那么 10 万行的表需要至少修改 6000 行才会触发。对于需要更精细统计信息的表，可以在表级别单独设置这两个值，例如ALTER TABLE ... SET (autovacuum_analyze_threshold = 500);。
4.2 采样率与 default_statistics_target：精度和性能的取舍
统计信息采样率由default_statistics_target控制，默认值是 100。它表示采用最多 100 个等频直方图桶、最多保留 100 个最频繁值等信息。如果你把它调高，比如调到 1000，那么直方图会更精确，但分析和存储统计信息的成本也会随之上升。
可以动态调整单列、单表的统计信息收集精度，而不影响全局配置。比如一个订单表的金额字段，千万行数据分布非常不均匀，这时候把该列的statistics_target调高到 500 或 1000，往往能显著提升等值查询和范围查询的估算准确性。我一般不会全局调大这个参数，因为全局成本收益比很差。更有价值的做法是只对关键字段单独设置。
4.3 大表统计信息：分区统计信息与增量统计信息
PostgreSQL 分区表默认会把子分区和父表的统计信息分开处理。如果某个分区被单独执行了ANALYZE，而父表没有参考所有分区的数据，父表上的统计信息可能会失真。早期版本中，对父表执行ANALYZE时不会同时递归分析所有子分区，需要显式加上ANALYZE或依赖自动分析。在较新版本里虽然有了递归能力，但依然要留意每个分区的统计信息是否完整。
当单个分区特别大且数据持续增长时，每次全量ANALYZE的成本很高。一种做法是只针对热点分区手动分析，另一个做法是使用pg_relation_size来筛选需要分析的大表。还可以使用增量统计信息，让优化器根据分区的统计信息汇总估算整个父表的分布。不过这要求所有分区都已完成独立的统计信息采集，而且汇总逻辑面对多列关联条件时依然手段有限，需要通过扩展统计信息来补强。
4.4 CREATE STATISTICS：解决多列关联条件下的估算失灵
普通统计信息只对单列有效。当查询条件中出现多个列，并且这些列之间存在明显相关性时，优化器通常会假设它们是相互独立的，这会导致严重的估算偏差。比如一个订单表里，城市字段和渠道字段高度相关（某些城市只走特定渠道），WHERE city = '某市' AND channel = '某渠道'的估算就会远高于实际返回行数。
CREATE STATISTICS可以创建扩展统计信息，支持ndistinct（多列去重）、dependencies（列相关性）、mcv（多列最频繁值）。它对提高多条件组合查询的准确性非常有效。不过要注意，不是所有场景都需要建扩展统计信息，只针对那些数据分布明显相关、并且业务 SQL 经常使用多列等值查询的字段组合，收益才最明显。
5. 让 DeepSeek 帮忙总结后，我反而更重视手工排查
5.1 让 AI 梳理知识边界很高效
我使用的做法，是把标题中提到的这类问题整理成一个提问：希望它从 PostgreSQL 优化器角度，解释统计信息的构成、过期带来的影响、排查方法以及调优手段。DeepSeek 给出了一整套完整提纲，甚至把pg_stats里面各字段的作用和典型误用场景都列了出来。相比自己翻文档，这个效率确实高很多。它可以帮你快速建立知识框架，避免一开始就陷入底层算法细节。
但它生成的某些问题排查命令需要实际验证。比如它可能建议你在生产环境直接执行CLUSTER来提升相关性，但CLUSTER会锁表，并且重建表数据，在关键业务表上并非什么时段都能操作。AI 给出的建议更多是“通用正确”，而不是“环境适用”。所以我把 AI 的总结看作一个起点，再结合自己的环境参数做二次筛选。
5.2 但 AI 给的结论必须放到真实环境里验证
我实际遇到过一个案例：应用侧在某个字段上做了等值查询，统计信息里的most_common_vals明明包含了目标值，但执行计划依然走了全表扫描。DeepSeek 给的通用建议是检查enable_seqscan设置或者索引是否失效。但真正的原因是该表上一个复合索引的前缀列与查询条件不匹配，导致优化器认为这个索引无法用于等值过滤，即使单列统计信息正常也无济于事。
这类问题只有通过查看EXPLAIN的结果才能找到。AI 再智能，也无法替你读取你数据库里的真实执行计划。所以我的原则是，把 AI 的输出当成“核对清单”，每一条都回到当前运行环境里验证。特别是链接计划的连接顺序、过滤条件、索引扫描的成本差异，必须具体到那个时刻的实际数据分布才能真正明白。
5.3 我现在的例行统计信息健康巡检
经过多次事故后，我现在会在每个核心业务表上检查三个点。第一，关键过滤列是否已定期ANALYZE，重点关注变化频繁的大表。第二，pg_stats中的n_distinct与真实去重值的偏差是否过大，如果偏差超过 30%，就考虑给该列调高statistics_target。第三，有没有存在多列强相关但没有创建扩展统计信息的字段组合。
这些检查我不会每次都手工执行，而是写成一个简单的巡检脚本。比如周期性查一下所有需要监控的大表最近一次ANALYZE时间，或者直接对比上一轮和这一轮统计信息中reltuples的波动幅度。如果波动异常大，就人工介入查看是否有数据迁移或大范围删除发生。
经验之谈：统计信息维护里最贵的不是
ANALYZE本身，而是因为统计信息不准导致选错执行计划从而浪费掉的查询时间。把有限的调优精力集中到最容易产生误差的列上，远比给所有表无差别调高采样率更有价值。
我在实际操作中最大的体会是：统计信息不是一把“设置完就能永远不管”的弦，而是一个需要持续观察的数据资产。它会随着业务写入模式、数据量级和查询模式的变化而动态失效。尤其要注意批量导入数据之后，手工执行一次ANALYZE已经成为了我的条件反射动作。
如果你也正在被“时快时慢”的查询折磨，不妨先从统计信息开始排查，用EXPLAIN看真实行数，再用pg_stats看估算依据，最后决定要不要调整采样率或建立扩展统计信息。这条路径不一定能解决所有性能问题，但一定能帮你排除掉优化器“瞎猜”这个高级坑位。
