PostgreSQL统计信息：SQL调优的“眼睛”与基石
前言
在PostgreSQL数据库运维和开发中，SQL性能问题时常让人头疼。一条本来很快的查询，随着数据量增长突然变慢；明明建了索引，优化器却选择全表扫描……这些问题的根源，往往与统计信息（Statistics）息息相关。
统计信息是PostgreSQL基于成本的优化器（CBO）决策的唯一依据。可以说，统计信息的准确与否，直接决定了SQL执行计划的好坏。本文将深入浅出地讲解PostgreSQL统计信息的作用、内容、工作原理，以及如何通过维护统计信息来高效调优SQL。
1. 统计信息是什么？为什么重要？
PostgreSQL本身不“认识”数据，它依靠统计信息来了解表中数据的分布、行数、重复值等特征。当执行一条SQL时，优化器会利用这些信息估算不同执行路径的代价（Cost），并选择代价最低的计划。
- 统计信息准确→ 优化器“看得清” → 选择最优计划（索引扫描、Hash Join等） → SQL飞驰。
- 统计信息过时或失真→ 优化器“盲人摸象” → 错误选择（例如小表变大表仍走全表扫描） → SQL慢如蜗牛。
因此，调优的第一步永远是：检查统计信息是否健康。
2. 统计信息包含哪些内容？
PostgreSQL的统计信息存储在系统表pg_class和pg_statistic中，通过视图pg_stats可以方便地查看列级统计。
2.1 表和索引级统计（pg_class）
| 字段 | 含义 |
|---|---|
reltuples | 表或索引的行数估计值 |
relpages | 占用的磁盘页数（8KB/页） |
这两个值是代价估算的基础。
2.2 列级统计（pg_stats）
| 字段 | 含义 | 调优用途 |
|---|---|---|
n_distinct | 不同值的数量（负数表示比例） | 判断列唯一性，影响索引选择 |
most_common_vals(MCV) | 最常见值列表 | 处理高频条件时估算更准 |
most_common_freqs | 对应MCV的频率 | 同上 |
histogram_bounds | 直方图边界（均匀分布） | 估算非高频值的等值或范围选择率 |
null_frac | NULL值比例 | 影响IS NULL条件 |
correlation | 物理顺序与逻辑顺序的相关性 | 决定索引扫描的额外IO代价 |
avg_width | 平均存储宽度（字节） | 影响内存使用和排序代价 |
3. 优化器是如何利用统计信息的？
一条SQL从解析到执行，优化器大致经历三个步骤：
3.1 估算选择度（Selectivity）
对于WHERE条件，优化器需要知道符合条件的行数占全表的比例。例如：
SELECT*FROMordersWHEREstatus='paid';优化器查询pg_stats，如果status列的MCV中有'paid'，则直接用其频率；否则利用直方图或均匀分布估算。
3.2 计算不同执行路径的代价
代价 = 磁盘IO + CPU计算 + 网络（忽略）。每个操作（顺序扫描、索引扫描、连接等）都有对应的代价参数（如seq_page_cost、random_page_cost），结合估算的行数和块数，计算出总代价。
3.3 选择代价最小的计划
优化器会枚举所有可能的连接顺序、扫描方式，最终选择总代价最低者。典型决策包括：
- 顺序扫描 vs 索引扫描：小表或返回大量数据时倾向顺序扫描。
- Nested Loop vs Hash Join vs Merge Join：根据驱动表大小、连接条件选择。
- 多表连接顺序：尽量先过滤小表。
4. 统计信息不准确的典型后果
- 索引失效：表实际有百万行，但
reltuples仍为旧值（如1000），优化器认为走索引代价高，从而选择全表扫描。 - 连接选择错误：错误估计驱动表行数，导致本该用Hash Join却用了Nested Loop，性能急剧下降。
- 内存分配不当：
work_mem等参数依赖估算，过估或低估都会影响排序、哈希操作的效率。
5. 如何维护和优化统计信息？
5.1 保持统计信息及时更新
- 开启 autovacuum（默认开启）：它会自动在数据变化达到阈值时触发
ANALYZE，更新统计信息。检查是否正常运行：
SELECTrelname,last_autoanalyze,autovacuum_countFROMpg_stat_user_tablesWHERErelname='your_table';- 手动执行 ANALYZE：在批量导入、大量UPDATE/DELETE后，及时手动分析：
ANALYZEyour_table;-- 只分析指定表ANALYZE;-- 分析整个库（谨慎使用）5.2 提高统计信息采样精度
默认采样目标default_statistics_target = 100，对于数据倾斜严重的列，可增大采样值：
-- 会话级临时调整SETdefault_statistics_target=200;-- 全局调整（修改 postgresql.conf）default_statistics_target=200-- 仅针对特定列（推荐）ALTERTABLEyour_tableALTERCOLUMNyour_columnSETSTATISTICS1000;调整后需重新执行ANALYZE生效。
5.3 处理多列关联：扩展统计信息（Extended Statistics）
当多个WHERE条件之间存在依赖关系时，常规统计假设列独立，会严重误估。例如WHERE city='北京' AND district='海淀'，实际上district几乎完全取决于city。此时可创建扩展统计：
-- 创建多列依赖统计CREATESTATISTICSstats_city_district(dependencies)ONcity,districtFROMaddresses;-- 创建多列不同值组合统计（更精确）CREATESTATISTICSstats_city_distinct(ndistinct)ONcity,districtFROMaddresses;-- 分析表ANALYZEaddresses;然后查询pg_stats_ext查看扩展统计信息。
6. 实战：检查统计信息是否“健康”的常用SQL
6.1 查看统计信息最后一次更新时间
SELECTschemaname,tablename,last_analyze,-- 手动 ANALYZE 时间last_autoanalyze,-- autovacuum 自动分析时间n_live_tup,-- 当前活跃行数估计n_dead_tup-- 死元组数（过大说明需要清理）FROMpg_stat_user_tablesWHEREtablename='your_table';如果last_autoanalyze很早，且n_dead_tup很大，说明 autovacuum 可能跟不上。
6.2 对比统计行数与真实行数
-- 统计信息中的行数SELECTreltuples::bigintFROMpg_classWHERErelname='your_table';-- 真实行数（精确计数，大表慎用）SELECTCOUNT(*)FROMyour_table;如果两者差异超过10%~20%，建议执行ANALYZE。
6.3 查看列统计详情
SELECTattname,n_distinct,null_frac,correlation,most_common_valsFROMpg_statsWHEREtablename='your_table'ANDattname='your_column';7. 总结
PostgreSQL的统计信息是优化器的“眼睛”，它决定了SQL执行计划的好坏。在调优过程中，请牢记以下几点：
- 统计信息及时性：确保
autovacuum正常工作，关键操作后手动ANALYZE。 - 统计信息准确性：针对倾斜列提高
STATISTICS目标，必要时使用扩展统计处理列关联。 - 定期巡检：通过系统视图监控统计信息状态，防患于未然。
当你遇到SQL性能突然下降时，不必急于改代码或加索引，先查统计信息——往往能快速定位并解决问题。掌握统计信息，就掌握了PostgreSQL调优的主动权。
