PostgreSQL在运行过程中会持续收集数据库内部的活动信息，其中表级别的统计数据都汇集在pg_stat_user_tables视图中。它不需要额外安装任何插件，直接查询就能看到每张用户表的扫描方式、行变更数量、autovacuum执行历史等信息。对于想了解数据库真实负载分布、判断索引是否有效、评估表是否需要维护的开发者和DBA来说，这个视图是最直接的入口。本文将系统介绍它的字段含义和实际应用方法。
pg_stat_user_tables的核心字段详解
pg_stat_user_tables本质上是一个基于底层统计收集器的视图，每个用户表对应一行数据。它包含的字段大致可以分为四组：扫描统计、元组统计、vacuum统计和锁统计。理解每个字段的含义，是后续做分析的基础。
扫描相关的字段包括seq_scan、seq_tup_read、idx_scan和idx_tup_fetch。其中seq_scan表示这张表被全表顺序扫描的次数，seq_tup_read记录顺序扫描过程中读取的行总数；idx_scan表示通过索引扫描访问这张表的次数，idx_tup_fetch是通过索引取回的行总数。通过对比这几组数字，可以直观判断一张表的访问模式。
元组统计字段包括n_tup_ins、n_tup_upd、n_tup_del、n_tup_hot_upd和n_live_tup、n_dead_tup。前四个分别记录插入、更新、删除和HOT更新的行数，后两个反映当前存活行和死元组的估计数量。n_dead_tup是一个需要重点关注的指标，它持续增长意味着autovacuum没有及时清理，表和索引会逐渐膨胀。
维护统计字段包括last_vacuum、last_autovacuum、last_analyze、last_autoanalyze以及对应的执行次数和耗时。锁统计字段n_tup_upd_upd_lock在早期版本中用于记录更新导致行锁等待的情况，不同版本字段略有差异，可以使用下面的SQL确认当前版本的实际结构：
SELECT column_name, data_type FROM information_schema.columns WHERE table_name = 'pg_stat_user_tables' ORDER BY ordinal_position;
利用扫描统计判断索引使用效率
在生产环境中，最常见的问题之一是查询没有走到索引，导致大量顺序扫描。通过seq_scan和idx_scan的对比可以快速定位这类表。如果一张数据量较大的表seq_scan很高而idx_scan接近于零，通常说明查询条件缺少合适的索引，或者统计信息过期导致优化器选择了错误的执行计划。
下面这个查询可以找出顺序扫描次数多且读取行数大的表，按累计读取量排序，这些表往往是性能优化的首要目标：
SELECT schemaname,
relname,
seq_scan,
seq_tup_read,
idx_scan,
idx_tup_fetch,
round(seq_tup_read::numeric / GREATEST(seq_scan, 1), 0) AS avg_rows_per_seq_scan
FROM pg_stat_user_tables
WHERE seq_scan > 0
ORDER BY seq_tup_read DESC
LIMIT 20;这个结果中的avg_rows_per_seq_scan列特别有参考价值。如果某张表平均每次顺序扫描要读取几十万行，而实际只需要返回少量结果，基本可以断定需要建索引。反过来，对于几十行的小表，顺序扫描反而比索引扫描更快，出现高seq_scan并不一定是问题，这是分析时要注意的细节。
另一个角度是评估现有索引的利用率。索引扫描次数长期为零的索引可能是无用索引，它们不仅占用存储，还会拖慢写入。可以结合pg_stat_user_indexes视图做交叉验证：
SELECT t.relname AS table_name,
i.relname AS index_name,
s.idx_scan,
s.idx_tup_read
FROM pg_stat_user_indexes s
JOIN pg_class t ON t.oid = s.relrelid
JOIN pg_class i ON i.oid = s.indexrelid
ORDER BY s.idx_scan ASC;监控死元组与autovacuum运行状况
PostgreSQL的MVCC机制决定了更新和删除不会立即移除旧版本数据，而是留下死元组等待vacuum清理。如果autovacuum参数配置不合理，或者表更新量极大，死元组会不断堆积，表现为查询变慢、表体积膨胀。pg_stat_user_tables中的n_dead_tup和last_autovacuum字段正是监控这一问题的抓手。
下面的查询列出死元组比例最高的表，帮助判断哪些表需要手工干预：
SELECT schemaname,
relname,
n_live_tup,
n_dead_tup,
round(n_dead_tup::numeric / GREATEST(n_live_tup + n_dead_tup, 1) * 100, 2) AS dead_ratio,
last_autovacuum,
autovacuum_count
FROM pg_stat_user_tables
WHERE n_dead_tup > 0
ORDER BY n_dead_tup DESC
LIMIT 20;如果某张表的dead_ratio超过百分之二十，且last_autovacuum时间久远，说明autovacuum的触发阈值可能设置得过松。默认情况下，autovacuum触发条件是死元组数超过autovacuum_vacuum_threshold加上autovacuum_vacuum_scale_factor乘以表行数，默认比例因子是0.2，对大表来说这意味着要积累大量死元组才会触发清理。可以对高更新表单独调小这个比例：
-- 针对高频更新的表单独设置更激进的autovacuum参数
ALTER TABLE my_hot_table SET (
autovacuum_vacuum_scale_factor = 0.02,
autovacuum_analyze_scale_factor = 0.01
);此外，n_tup_hot_upd与n_tup_upd的比值反映了HOT更新的占比。HOT更新不需要更新索引，开销更低。如果这个比值很低，通常是因为更新命中了被索引覆盖的列，可以考虑调整索引设计，减少不必要的索引列，从而提高HOT更新比例。
统计信息的重置与使用注意事项
所有统计数据都是自收集器启动或上次重置以来的累计值，这一点在使用时必须牢记。例如某张表的seq_scan很高，可能是三年前某次误操作留下的历史记录，并不代表当前负载。可以通过pg_stat_reset()清零所有统计，或者用pg_stat_reset_single_table_counters只重置某张表的计数器：
-- 重置指定表的统计计数器
SELECT pg_stat_reset_single_table_counters('public.orders'::regclass);一个实用的做法是在性能排查开始前重置统计，然后让系统运行一段时间（比如高峰期一小时），再查询数据，这样得到的结论针对性强得多。另外要注意，统计数据不是实时精确的，收集器每隔stats_flush_interval左右批量写入一次，短时间内的活动可能有延迟。
最后需要提醒的是，pg_stat_user_tables只包含用户表，系统表的活动记录在pg_stat_sys_tables中，所有表的合并视图是pg_stat_all_tables。在做全库巡检脚本时，应根据分析目的选择合适的视图，并结合pg_class中的表大小信息一起呈现，才能形成一份完整的表级别健康报告。定期采集这些统计快照并保存历史趋势，也是容量规划和性能回归分析的重要数据来源。
pg_stat_user_tablesPostgreSQL统计信息表级别监控修改时间：2026-09-01 13:32:36