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 条件，优化器需要知道符合条件的行数占全表的比例。例如：
sql
SELECT * FROM orders WHERE status = '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，更新统计信息。检查是否正常运行：
sql
SELECT relname, last_autoanalyze, autovacuum_count
FROM pg_stat_user_tables
WHERE relname = 'your_table';- 手动执行 ANALYZE：在批量导入、大量UPDATE/DELETE后，及时手动分析：
sql
ANALYZE your_table; -- 只分析指定表
ANALYZE; -- 分析整个库（谨慎使用）5.2 提高统计信息采样精度
默认采样目标 default_statistics_target = 100，对于数据倾斜严重的列，可增大采样值：
sql
-- 会话级临时调整
SET default_statistics_target = 200;
-- 全局调整（修改 postgresql.conf）
default_statistics_target = 200
-- 仅针对特定列（推荐）
ALTER TABLE your_table ALTER COLUMN your_column SET STATISTICS 1000;调整后需重新执行 ANALYZE 生效。
5.3 处理多列关联：扩展统计信息（Extended Statistics）
当多个 WHERE 条件之间存在依赖关系时，常规统计假设列独立，会严重误估。例如 WHERE city='北京' AND district='海淀'，实际上 district 几乎完全取决于 city。此时可创建扩展统计：
sql
-- 创建多列依赖统计
CREATE STATISTICS stats_city_district (dependencies) ON city, district FROM addresses;
-- 创建多列不同值组合统计（更精确）
CREATE STATISTICS stats_city_distinct (ndistinct) ON city, district FROM addresses;
-- 分析表
ANALYZE addresses;然后查询 pg_stats_ext 查看扩展统计信息。
6. 实战：检查统计信息是否"健康"的常用SQL
6.1 查看统计信息最后一次更新时间
sql
SELECT
schemaname,
tablename,
last_analyze, -- 手动 ANALYZE 时间
last_autoanalyze, -- autovacuum 自动分析时间
n_live_tup, -- 当前活跃行数估计
n_dead_tup -- 死元组数（过大说明需要清理）
FROM pg_stat_user_tables
WHERE tablename = 'your_table';如果 last_autoanalyze 很早，且 n_dead_tup 很大，说明 autovacuum 可能跟不上。
6.2 对比统计行数与真实行数
sql
-- 统计信息中的行数
SELECT reltuples::bigint FROM pg_class WHERE relname = 'your_table';
-- 真实行数（精确计数，大表慎用）
SELECT COUNT(*) FROM your_table;如果两者差异超过10%~20%，建议执行 ANALYZE。
6.3 查看列统计详情
sql
SELECT
attname,
n_distinct,
null_frac,
correlation,
most_common_vals
FROM pg_stats
WHERE tablename = 'your_table' AND attname = 'your_column';7. 总结
PostgreSQL的统计信息是优化器的"眼睛"，它决定了SQL执行计划的好坏。在调优过程中，请牢记以下几点：
- 统计信息及时性 ：确保
autovacuum正常工作，关键操作后手动ANALYZE。 - 统计信息准确性 ：针对倾斜列提高
STATISTICS目标，必要时使用扩展统计处理列关联。 - 定期巡检：通过系统视图监控统计信息状态，防患于未然。
当你遇到SQL性能突然下降时，不必急于改代码或加索引，先查统计信息------往往能快速定位并解决问题。掌握统计信息，就掌握了PostgreSQL调优的主动权。