pg_stats：Postgres 内部统计机制详解

关注

原创最新推荐文章于 2026-09-24 23:52:16 发布 316 阅读 AI 写同款· GEO 优化 ›

Postgres MCP集群慢查询调优实战：从统计偏差到分布式执行闭环 Postgres作为主流关系型数据库，其性能优化常聚焦于SQL写法、索引设计与单机统计信息。但在MCP（Multi-Cluster Protocol）架构下，数据库演变为跨节点协同系统，传统调优方法失效。MCP本质是Postgres的分布式协调层，不存储数据，却深度影响查询规划——因各节点pg_statistic统计偏差（如ndistinct低估）、WSS传输延迟、协调层元数据不同步，导致同一SQL在不同节点执行耗时差异巨大。技术价值在于将‘单机优化思维’升级为‘协同面治理能力’，支撑Supabase、Ne 阅读详情

概述

本文梳理 PostgreSQL 内部统计的核心原理与 pg_stats 视图运行机制，内容源自 POSETTE 2026 技术分享。文章系统性讲解 pg_stats 的定义、生成逻辑，以及其对 Postgres 查询规划器决策的核心影响，帮助读者全面掌握数据库统计数据驱动 SQL 执行计划的底层逻辑。

本文以业务常用的 customers 数据表作为演示案例：

CREATE TABLE customers (
    id          bigserial PRIMARY KEY,
    city        text NOT NULL,
    state       text NOT NULL,
    signup_date date NOT NULL
);
-- Insert 1,000,000 rows

以下是日常业务中高频使用的筛选查询语句：

SELECT * FROM customers WHERE state = 'CA';

该表已为 state 和 city 字段分别创建独立索引。常规认知中，数据库会优先走 state 字段的索引扫描，但 EXPLAIN ANALYZE 的实际执行结果却截然不同：

QUERY PLAN
-----------------------------------------------------------------
 Seq Scan on customers  (cost=0.00..19682.66 rows=173829 width=26)
                        (actual time=0.025..120.574 rows=172001 loops=1)
   Filter: (state = 'CA'::text)
   Rows Removed by Filter: 827972
   Buffers: shared hit=4601 read=2582
 Planning:   Buffers: shared hit=139
 Planning Time: 0.371 ms
 Execution Time: 128.136 ms

数据表存在有效索引的前提下，数据库最终选择了顺序扫描。本文将深入解析这一现象背后的统计机制原理。

查询计划由查询规划器生成

Postgres 接收 SQL 查询请求后，会通过内置查询规划器生成执行计划。规划器不会直接读取、解析数据表原始数据，所有执行决策均依托于系统表 pg_statistic中存储的数据汇总信息。

pg_statistic 存储的汇总数据，包含规划器判定执行计划所需的各类核心维度信息：

数据表中各个字段的唯一值数量
字段的高频取值及其出现频率
字段数值在取值区间内的整体分布规律
数据在磁盘上的物理存储顺序与字段逻辑排序顺序的匹配度

pg_statistic 的原始数据为机器优化格式，可读性极差。为方便人工查询与使用，Postgres 封装了 pg_stats 视图，以标准化、易读的形式展示所有统计信息。

ANALYZE：统计数据的生成与更新机制

pg_statistic 中的汇总数据无法自动生成，所有统计指标均通过 ANALYZE 命令生成并刷新。

ANALYZE customers;

ANALYZE 会对目标表执行全表扫描或抽样扫描，计算每个字段的多维统计指标，并将结果写入 pg_statistic 系统表。Postgres 的自动真空清理机制会在后台自动执行 ANALYZE，但大批量数据载入、数据迁移等场景下，需手动执行该命令更新实时统计数据。
针对 customers 表执行统计查询，查看核心字段指标：

SELECT attname, n_distinct, null_frac, correlation
FROM pg_stats
WHERE tablename = 'customers'
ORDER BY attname;
  attname    | n_distinct | null_frac |  correlation
--------------+------------+-----------+--------------
city         |      10106 |         0 |  0.0021338463
id           |         -1 |         0 |             1
signup_date  |       1822 |         0 |             1
state        |         50 |         0 |    0.06440461
(4 rows)

核心指标释义如下：

n_distinct：字段唯一值的估算数量。state 字段恰好有 50 个唯一值，与美国州的数量匹配；city 字段存在 10106 个唯一值，符合美国城市数据分布特征。主键 id 取值为 -1，是字段唯一无重复的固定标识。
null_frac：字段空值占总行数的比例。示例中所有字段均定义为非空，因此该指标全部为 0。
correlation：取值范围为 -1 至 +1，用于衡量数据磁盘物理存储顺序与字段逻辑排序顺序的匹配程度。取值 +1 代表数据在磁盘上完全有序（自增 ID、增量日期字段均符合该特征）；取值趋近于 0 代表数据存储顺序相对字段值随机；取值趋近于 ±1 时，数据库更倾向于走索引扫描；取值趋近于 0 时，索引扫描成本更高，更易触发顺序扫描。该指标会作为系数参与规划器的成本计算。

高频值统计（MCV）

ANALYZE 会采集字段的高频取值及对应出现频率，两类数据分别存储在 pg_stats 的 most_common_vals 和 most_common_freqs 平行数组中。

以 state 字段为例，查询其高频值分布数据：

SELECT
   unnest(most_common_vals::text::text[]) AS state,
   unnest(most_common_freqs)              AS frequency
FROM pg_stats
WHERE tablename = 'customers' AND attname = 'state'
LIMIT 5;
state |  frequency
-------+-------------
CA    |  0.17403333
TX    |      0.1165
NY    |  0.08586667
FL    |      0.0666
IL    |      0.0474
(5 rows)

统计结果显示，state=CA 的数据占比约 17.4%，state=TX 占比约 11.6%。高频值的频率数据是规划器估算扫描行数、选择执行扫描方式的核心依据。

成本机制：规划器的计划选择逻辑

查询规划器基于成本计算结果筛选最优执行计划，影响计划选择的三大核心成本参数如下：

random_page_cost：随机读取磁盘页的成本，对应索引扫描+回表查询场景
seq_page_cost：顺序读取磁盘页的成本，对应全表顺序扫描场景
cpu_tuple_cost：处理单行数据的 CPU 计算成本

结合 pg_statistic 生成的行数估算数据，上述成本参数共同决定规划器的两类核心执行选择：

扫描类型

顺序扫描（Sequential Scan）
索引扫描（Index Scan）
位图堆扫描（Bitmap Heap Scan）

连接类型

嵌套循环连接（Nested Loop）
哈希连接（Hash Join）
合并连接（Merge Join）

规划器会生成多个候选执行计划，计算各计划的总成本，最终选取成本最低的方案执行。失真或过期的统计数据会导致行数估算错误，进而引发执行计划不合理、SQL 性能下降。精准的统计数据是高效查询执行的核心前提。

两类取值的查询计划差异解析

对比查询 state 字段高频值 CA 与低频值 WY 的执行计划：

EXPLAIN ANALYZE SELECT * FROM customers WHERE state = 'CA';
-- Seq Scan on customers  (cost=0.00..19682.66 rows=174029 ...)
--                        (actual time=0.042..50.257 rows=172001 loops=1)

EXPLAIN ANALYZE SELECT * FROM customers WHERE state = 'WY';
-- Index Scan using customers_state_idx on customers
--    (cost=0.42..13116.39 rows=4233 ...)
--    (actual time=0.045..21.238 rows=4300 loops=1)

state=CA 的数据占全表约 18%，近 18 万行。针对大规模匹配数据，索引扫描需要反复执行索引检索与磁盘页读取，综合成本远高于全表顺序扫描，因此规划器优先选择顺序扫描。

state=WY 的匹配数据仅约 4000 行，数据选择性极低，索引扫描的效率优势显著，因此规划器触发索引扫描。

可通过手动关闭顺序扫描功能，验证成本判定逻辑的合理性：

SET enable_seqscan = off;

EXPLAIN ANALYZE SELECT * FROM customers WHERE state = 'CA';
--  Index Scan using customers_state_idx on customers
--    (cost=0.42..32172.73 rows=170529 width=26)
--    (actual time=0.053..75.656 rows=172001 loops=1)

强制走索引扫描后，执行成本从 19682 升至 32172，验证了原顺序扫描计划为最优选择。高频值统计数据精准识别了 CA 的高占比特征，帮助规划器规避低效的索引扫描，充分体现了高频值统计在倾斜数据场景下的核心价值。

直方图：适配非等值范围查询

高频值统计仅适用于等值查询场景。针对时间范围筛选、数值区间对比等范围查询，ANALYZE 会生成字段直方图统计数据，辅助规划器完成计划判定。

Postgres 默认生成 100 个等深直方图桶，每个桶承载的数据行数基本一致。查询 signup_date 字段的直方图边界数据：

SELECT (unnest(histogram_bounds::text::date[]))::date AS bucket_bound
FROM pg_stats
WHERE tablename = 'customers' AND attname = 'signup_date'
LIMIT 8;
 bucket_bound
--------------
 2018-01-01
 2018-03-01
 2018-04-28
 2018-07-04
 2018-09-05
 2018-10-28
 2018-12-27
 2019-02-14
(8 rows)

默认直方图桶的粒度覆盖约两个月数据，可满足常规查询估算需求。对于时间、数值分布倾斜的大表，增加直方图桶数量可大幅提升范围查询的行数估算精度。

直方图精度直接影响规划器判定效果：低精度桶仅能判断数据大致分布区间，高精度桶可精准识别数据峰值、谷值及细分分布规律，为精细化范围查询的计划选择提供精准依据。

支持自定义单字段统计精度、增加直方图桶数量：

ALTER TABLE customers
    ALTER COLUMN signup_date SET STATISTICS 1000;
ANALYZE customers;

调整精度并重新采集统计数据后，signup_date 字段的直方图桶粒度缩短至约两天，数据分布识别精度大幅提升：

bucket_bound
--------------
 2018-01-01
 2018-01-03
 2018-01-05
 2018-01-07
 2018-01-10
 2018-01-12
 2018-01-14
 2018-01-16
(8 rows)

精度与性能需平衡取舍：直方图桶数量越多，估算精度越高，但会增加 ANALYZE 计算开销与 SQL 规划开销。不建议修改全局默认统计精度，仅针对估算异常的业务字段做定向优化。

字段关联统计

单字段统计可满足绝大多数单条件查询场景，多字段联合筛选场景下，规划器默认的字段独立统计逻辑会产生严重估算偏差。

执行 city 与 state 双字段联合筛选查询：

EXPLAIN ANALYZE
SELECT * FROM customers
WHERE city = 'Cheyenne' AND state = 'WY';

-- Index Scan on customers  (cost=... rows=8 width=...)
--                          (actual rows=4012)

规划器估算返回 8 行数据，实际查询结果为 4012 行，估算偏差达 500 倍。

问题核心在于，规划器默认所有字段统计相互独立，通过多字段独立概率的乘积计算匹配数据量：

[P(\text{city} = \text{Cheyenne} ;\wedge; \text{state} = \text{WY}) = P(\text{city}) \times P(\text{state})]

实际业务数据中，city 与 state 字段存在强关联关系，city = 'Cheyenne' 绝大多数隶属于 state = 'WY' 。默认的独立统计逻辑无法识别该关联特征，最终导致严重估算偏差。

Postgres 10 及以上版本支持自定义扩展统计，用于识别字段关联关系：

CREATE STATISTICS customers_city_state (dependencies, ndistinct)
ON city, state FROM customers;

ANALYZE customers;

dependencies 与 ndistinct 参数分别用于采集字段间关联关系、唯一值关联信息。重新执行 ANALYZE 更新统计数据后，查询计划估算精度大幅优化：

EXPLAIN ANALYZE
SELECT * FROM customers
WHERE city = 'Cheyenne' AND state = 'WY';

-- Index Scan on customers  (cost=... rows=4087 width=...)
--                          (actual rows=4012)

优化后估算行数 4087 与实际行数 4012 基本吻合。精准的底层行数估算，可避免上层关联、聚合逻辑产生连锁错误。底层统计偏差会在多层执行计划中持续放大，最终导致复杂查询整体性能劣化。