PostgreSQL 表膨胀与索引维护 100 条命令

DBA100

100 条命令系列文章专栏

PostgreSQL 表膨胀与索引维护 100 条命令

前言

PostgreSQL 更新或删除行时，旧版本不会立刻从数据文件里消失。VACUUM 负责回收可再利用的空间，也负责推进事务 ID 冻结边界。平时看到磁盘涨、死元组多，或日志里出现 wraparound 警告，不能只凭一张表的大小就决定跑 VACUUM FULL。

这篇把表统计、autovacuum、冻结年龄和膨胀判断放在一起。先弄清是哪张表增长、VACUUM 为什么没跟上，再决定要不要人工维护。需要排查时可以直接翻，建议收藏并分享给值班同事。

PostgreSQL VACUUM 与冻结年龄排查图 PostgreSQL VACUUM 与冻结年龄排查图

示例为 PostgreSQL 17，SQL 默认连接目标数据库。统计值可能有延迟，死元组是估计数；涉及重写表和索引的操作要另外评估锁、磁盘和执行窗口。

先找出增长的表

1. 查看数据库当前占用

SQL

1SELECT datname, pg_size_pretty(pg_database_size(oid)) AS database_size
2FROM pg_database
3WHERE datallowconn
4ORDER BY pg_database_size(oid) DESC;

先确认是不是整个库都涨了。这个结果是数据库对象占用，不包括 WAL 归档和外部备份目录。

2. 按表总大小排序

SQL

1SELECT schemaname, relname,
2       pg_size_pretty(pg_total_relation_size(relid)) AS total_size,
3       pg_total_relation_size(relid) AS total_bytes
4FROM pg_stat_user_tables
5ORDER BY total_bytes DESC
6LIMIT 30;

pg_total_relation_size 包含表、索引和 TOAST。它适合找大对象，不能直接把大小当成膨胀量。

3. 分开查看表、索引和 TOAST 占用

SQL

1SELECT pg_size_pretty(pg_relation_size('public.orders'::regclass)) AS heap,
2       pg_size_pretty(pg_indexes_size('public.orders'::regclass)) AS indexes,
3       pg_size_pretty(pg_total_relation_size('public.orders'::regclass)
4                      - pg_relation_size('public.orders'::regclass)
5                      - pg_indexes_size('public.orders'::regclass)) AS toast_and_aux;

替换成现场表名。若总大小主要来自索引，后面就不能只盯表的 VACUUM；若来自 TOAST，还要继续查大字段的更新方式。

4. 查看活元组、死元组与最近 VACUUM

SQL

1SELECT schemaname, relname, n_live_tup, n_dead_tup,
2       last_vacuum, last_autovacuum, vacuum_count, autovacuum_count
3FROM pg_stat_user_tables
4ORDER BY n_dead_tup DESC
5LIMIT 30;

n_dead_tup 是估计值。高值且 last_autovacuum 长时间没推进，才值得继续看阈值、进程和长事务；数值为零也不能证明表没有空间浪费。

5. 查看最近一次 ANALYZE 和修改量

SQL

1SELECT schemaname, relname, n_mod_since_analyze,
2       last_analyze, last_autoanalyze
3FROM pg_stat_user_tables
4ORDER BY n_mod_since_analyze DESC
5LIMIT 30;

VACUUM 解决旧版本清理，ANALYZE 更新优化器统计。大量变更后执行计划异常时，不要把统计信息过旧和表膨胀混成一个问题。

看 VACUUM 有没有跟上

6. 查看全局 autovacuum 参数

SQL

1SELECT name, setting, unit, source
2FROM pg_settings
3WHERE name IN ('autovacuum', 'autovacuum_max_workers',
4               'autovacuum_vacuum_threshold', 'autovacuum_vacuum_scale_factor',
5               'autovacuum_vacuum_insert_threshold',
6               'autovacuum_vacuum_insert_scale_factor')
7ORDER BY name;

普通清理按基础阈值加表行数比例触发，大表采用默认比例时可能积累很多死元组。还要核对表级存储参数，不能只看全局配置。

7. 查看表级 autovacuum 设置

SQL

1SELECT c.oid::regclass AS table_name, c.reloptions
2FROM pg_class AS c
3WHERE c.oid = 'public.orders'::regclass;

reloptions 为 NULL 通常表示没有表级覆盖。看到 autovacuum_enabled=false 时也别认为冻结风险已关闭；达到事务 ID 安全阈值时仍会强制执行防回卷 VACUUM。

8. 查看当前 VACUUM 任务

SQL

1SELECT a.pid, a.backend_type, a.state, a.wait_event_type,
2       a.wait_event, a.query_start, a.query
3FROM pg_stat_activity AS a
4WHERE a.backend_type = 'autovacuum worker'
5   OR a.query ILIKE 'VACUUM%'
6ORDER BY a.query_start;

读进程和等待事件。VACUUM 在运行但死元组仍持续增长，可能是任务追不上写入，也可能有长事务阻止旧版本清理；要看后续指标再判断。

9. 查看每个数据库的冻结年龄

SQL

1SELECT datname, age(datfrozenxid) AS xid_age
2FROM pg_database
3ORDER BY xid_age DESC;

datfrozenxid 是数据库内最老未冻结事务 ID 的下界。年龄高时要继续定位具体表和 TOAST，而不是直接给所有表跑 VACUUM FULL。

10. 查看表和 TOAST 的冻结年龄

SQL

1SELECT c.oid::regclass AS table_name,
2       greatest(age(c.relfrozenxid), age(t.relfrozenxid)) AS xid_age
3FROM pg_class AS c
4LEFT JOIN pg_class AS t ON t.oid = c.reltoastrelid
5WHERE c.relkind IN ('r', 'm')
6ORDER BY xid_age DESC
7LIMIT 30;

参考官方的查询方式，把 TOAST 一起算进去。最老的表未必最大；如果年龄接近 autovacuum_freeze_max_age，优先看防回卷 VACUUM 是否能运行以及有没有长期保留旧 XID 的会话或复制槽。

11. 查看普通 VACUUM 当前处理的阶段

SQL

1SELECT pid, datname, relid::regclass AS table_name, phase,
2       heap_blks_total, heap_blks_scanned, heap_blks_vacuumed
3FROM pg_stat_progress_vacuum
4ORDER BY pid;

这张视图只显示正在执行的普通 VACUUM；VACUUM FULL 的进度在 pg_stat_progress_cluster。扫描块数包含借助可见性映射跳过的块，不能把它当成实际逐页读盘量。

12. 查看索引清理是否反复循环

SQL

1SELECT pid, relid::regclass AS table_name, phase,
2       index_vacuum_count, dead_tuple_bytes,
3       max_dead_tuple_bytes, indexes_total, indexes_processed
4FROM pg_stat_progress_vacuum
5ORDER BY index_vacuum_count DESC;

index_vacuum_count 反复增长，说明一次扫描里要多轮清索引。结合死元组量、索引个数以及 maintenance_work_mem/autovacuum_work_mem 判断原因，别只看扫描百分比。

13. 查 VACUUM 进程当前等什么

SQL

1SELECT a.pid, p.relid::regclass AS table_name, p.phase,
2       a.wait_event_type, a.wait_event, a.state
3FROM pg_stat_progress_vacuum AS p
4JOIN pg_stat_activity AS a USING (pid)
5ORDER BY a.pid;

VacuumDelay 可能是成本限速；Lock、IO 或长时间不变的阶段需要分别追。state='active' 也可能正在等待，不能只看状态列。

清不掉时查事务边界

14. 找出长时间未结束的事务

SQL

1SELECT pid, datname, usename, state, xact_start,
2       now() - xact_start AS xact_age,
3       backend_xid, backend_xmin, left(query, 120) AS query
4FROM pg_stat_activity
5WHERE xact_start IS NOT NULL
6ORDER BY xact_start
7LIMIT 30;

特别留意 idle in transaction。长期持有快照可能让旧行版本暂时无法清理；先确认对应业务连接和事务用途，再决定如何结束，不要看见最老 PID 就直接终止。

15. 按 backend_xmin 年龄排查会话

SQL

1SELECT pid, usename, state, xact_start,
2       age(backend_xmin) AS xmin_age,
3       left(query, 120) AS query
4FROM pg_stat_activity
5WHERE backend_xmin IS NOT NULL
6ORDER BY xmin_age DESC
7LIMIT 30;

这比仅按事务开始时间排序更贴近 VACUUM 的可见性边界。结果可能因权限受限而缺少其他会话详情，诊断账号需有读取全局统计的权限。

16. 查看复制槽保留的最老事务

SQL

1SELECT slot_name, slot_type, database, active,
2       xmin, age(xmin) AS xmin_age,
3       catalog_xmin, age(catalog_xmin) AS catalog_xmin_age
4FROM pg_replication_slots
5WHERE xmin IS NOT NULL OR catalog_xmin IS NOT NULL
6ORDER BY greatest(coalesce(age(xmin), 0),
7                  coalesce(age(catalog_xmin), 0)) DESC;

复制槽的 xmin 和 catalog_xmin 会限制对应旧版本的清理。槽不活跃也不能直接删除：仍在使用它的备库或逻辑订阅可能需要重建。先找到消费者和保留目的。

17. 查看备库反馈的 xmin 边界

SQL

1-- 在主库执行
2SELECT application_name, client_addr, state,
3       backend_xmin, age(backend_xmin) AS xmin_age
4FROM pg_stat_replication
5WHERE backend_xmin IS NOT NULL
6ORDER BY xmin_age DESC;

启用 hot_standby_feedback 的备库可能向主库报告它仍需要的旧快照。复制延迟、长读事务和主库表膨胀要结合起来看；这里为空不能证明备库完全没有影响。

18. 检查长期未决的两阶段事务

SQL

1SELECT gid, "transaction" AS xid, age("transaction") AS xid_age,
2       prepared, owner, database
3FROM pg_prepared_xacts
4ORDER BY xid_age DESC
5LIMIT 30;

未提交或回滚的 prepared transaction 也可能保留旧 XID。是否提交必须由业务事务协调方确认；贸然回滚会破坏跨系统事务的一致性。

19. 查看冻结相关的全局阈值

SQL

1SELECT name, setting, unit, source
2FROM pg_settings
3WHERE name IN ('autovacuum_freeze_max_age', 'vacuum_freeze_min_age',
4               'vacuum_freeze_table_age', 'autovacuum_multixact_freeze_max_age',
5               'vacuum_multixact_freeze_min_age',
6               'vacuum_multixact_freeze_table_age')
7ORDER BY name;

age(relfrozenxid) 要和防回卷阈值一起看。不要通过提高阈值来掩盖清理任务跑不动；XID 与 multixact 有各自的冻结年龄。

20. 找出最老的 multixact 表

SQL

1SELECT c.oid::regclass AS table_name,
2       greatest(mxid_age(c.relminmxid), mxid_age(t.relminmxid)) AS mxid_age
3FROM pg_class AS c
4LEFT JOIN pg_class AS t ON t.oid = c.reltoastrelid
5WHERE c.relkind IN ('r', 'm')
6ORDER BY mxid_age DESC
7LIMIT 30;

多事务共同锁行会使用 multixact ID。排查防回卷不能只看 relfrozenxid，还要看 relminmxid；老龄表仍需结合 VACUUM 任务和日志确认是否正在推进。

估算可复用空间

21. 确认当前数据库装了 pgstattuple

SQL

1SELECT extname, extversion, extnamespace::regnamespace AS extension_schema
2FROM pg_extension
3WHERE extname = 'pgstattuple';

后面的 pgstattuple_approx 和 pgstatindex 来自这个扩展，没安装就不能直接运行。安装扩展属于数据库变更，应在维护流程里处理，不能在读诊断命令时顺手装上。

22. 快速估算目标表的死元组和空闲空间

SQL

1-- 当前库已安装 pgstattuple
2SELECT table_len, scanned_percent, dead_tuple_count,
3       dead_tuple_percent, approx_free_space, approx_free_percent
4FROM pgstattuple_approx('public.orders'::regclass);

它利用可见性映射跳过部分页面，scanned_percent 会告诉你实际扫描比例。死元组统计和空闲空间估计应分开看：后者通常是表内可再利用空间，不等于 VACUUM 之后能归还给文件系统的字节数。

23. 在小表上做完整 pgstattuple 扫描

SQL

1-- 当前库已安装 pgstattuple；先评估目标表的大小
2SELECT table_len, tuple_count, dead_tuple_count,
3       dead_tuple_len, free_space, free_percent
4FROM pgstattuple('public.orders'::regclass);

它会扫描整张表，比 pgstattuple_approx 更重。并发写入时结果也不是整个扫描期间的同一瞬间快照；大表值班排查优先用上一条做初筛。

24. 查目标表的索引占用

SQL

1SELECT i.indexrelid::regclass AS index_name,
2       pg_size_pretty(pg_relation_size(i.indexrelid)) AS index_size,
3       pg_relation_size(i.indexrelid) AS index_bytes
4FROM pg_index AS i
5WHERE i.indrelid = 'public.orders'::regclass
6ORDER BY index_bytes DESC;

如果总占用主要来自几个大索引，先确认索引类型、使用情况和页密度，再考虑重建。索引文件大不等于索引失效。

25. 查看 B-tree 索引页密度

SQL

1-- 当前库已安装 pgstattuple；替换为现场 B-tree 索引
2SELECT index_size, leaf_pages, deleted_pages,
3       avg_leaf_density, leaf_fragmentation
4FROM pgstatindex('public.orders_pkey'::regclass);

pgstatindex 只用于 B-tree 索引。平均叶页密度偏低可能值得调查，但要结合填充因子、更新模式和索引增长趋势；单次结果不能直接推导出应重建多少空间。

26. 查看 GIN 索引的 pending list

SQL

1-- 当前库已安装 pgstattuple；替换为现场 GIN 索引
2SELECT pending_pages, pending_tuples
3FROM pgstatginindex('public.orders_tags_gin'::regclass);

GIN 索引才有这个 pending list。积累较多时结合写入速率、fastupdate 与维护任务看原因；不要把它和 B-tree 的叶页密度混在一起判断。

27. 查看目标表对应的 TOAST 对象

SQL

1SELECT c.oid::regclass AS table_name,
2       c.reltoastrelid::regclass AS toast_name,
3       pg_size_pretty(pg_total_relation_size(c.reltoastrelid)) AS toast_size
4FROM pg_class AS c
5WHERE c.oid = 'public.orders'::regclass
6  AND c.reltoastrelid <> 0;

频繁更新大字段会让 TOAST 也增长。表主体看着不大而总大小明显更大时，先查这一路；没有 TOAST 对象就不会返回行。

28. 查看 pg_class 对目标表的行数和页数估计

SQL

1SELECT oid::regclass AS table_name, relpages, reltuples,
2       pg_relation_size(oid) AS actual_heap_bytes,
3       current_setting('block_size') AS block_size
4FROM pg_class
5WHERE oid = 'public.orders'::regclass;

relpages、reltuples 是规划器使用的估计值，VACUUM/ANALYZE 后会更新；实际文件大小则由 pg_relation_size 读取。两者不同时先看统计信息更新时间，不要直接算成“膨胀百分比”。

29. 定位目标表的数据库文件相对路径

SQL

1SELECT 'public.orders'::regclass AS table_name,
2       pg_relation_filepath('public.orders'::regclass) AS relation_path;

输出是相对于数据目录或表空间位置的路径，用于和服务器文件系统占用对照。数据库对象可能有多个文件段，不能只看这一条返回的单个路径判断总大小。

人工维护前先定目标

30. 对目标表执行普通 VACUUM ANALYZE

SQL

1-- 先确认业务窗口、写入负载和长事务
2VACUUM (VERBOSE, ANALYZE) public.orders;

它清理可回收的旧版本并更新统计，通常允许表继续读写；普通 VACUUM 大多只是把空间留在表内复用。若目的是让文件系统马上释放大量空间，不能把它当成 VACUUM FULL 的等价命令。VACUUM 也不能放在事务块中执行。

autovacuum 为什么还没轮到这张表

31. 估算死元组触发阈值

SQL

1SELECT c.oid::regclass AS table_name, s.n_dead_tup,
2       c.reltuples AS estimated_rows,
3       current_setting('autovacuum_vacuum_threshold')::integer
4       + current_setting('autovacuum_vacuum_scale_factor')::numeric
5         * GREATEST(c.reltuples, 0) AS global_vacuum_threshold
6FROM pg_class AS c
7JOIN pg_stat_user_tables AS s ON s.relid = c.oid
8WHERE c.oid = 'public.orders'::regclass;

autovacuum 的基础阈值加上行数比例，决定了普通死元组触发条件。这里按全局参数估算；目标表若设置了自己的 autovacuum_vacuum_* 存储参数，应以第 7 条查出的表级值重新计算。reltuples 和 n_dead_tup 都是估计值，不能把“低于阈值”当成永不清理的保证。

32. 检查纯插入表是否达到插入触发阈值

SQL

1SELECT c.oid::regclass AS table_name, s.n_ins_since_vacuum,
2       current_setting('autovacuum_vacuum_insert_threshold')::integer
3       + current_setting('autovacuum_vacuum_insert_scale_factor')::numeric
4         * GREATEST(c.reltuples, 0) AS global_insert_threshold,
5       s.last_autovacuum
6FROM pg_class AS c
7JOIN pg_stat_user_tables AS s ON s.relid = c.oid
8WHERE c.oid = 'public.orders'::regclass;

INSERT 多、UPDATE/DELETE 少的表，死元组未必高，仍可能因为新插入行数触发 VACUUM，推进可见性和冻结。表级参数同样可能覆盖全局值；统计系统更新有延迟，读数接近阈值时还要看最近一次 autovacuum 是否已经运行。

33. 算目标表自动 ANALYZE 的触发门槛

SQL

1SELECT c.oid::regclass AS table_name, s.n_mod_since_analyze,
2       current_setting('autovacuum_analyze_threshold')::integer
3       + current_setting('autovacuum_analyze_scale_factor')::numeric
4         * GREATEST(c.reltuples, 0) AS global_analyze_threshold,
5       s.last_autoanalyze
6FROM pg_class AS c
7JOIN pg_stat_user_tables AS s ON s.relid = c.oid
8WHERE c.oid = 'public.orders'::regclass;

有些表空间增长不明显，计划却变差，问题可能是统计信息没及时更新。这里看修改量是否接近 ANALYZE 门槛；表级覆盖参数和分区父表的特殊情况要单独核对，不能拿这一个全局公式解释所有表。

34. 找出明确关闭常规 autovacuum 的用户表

SQL

1SELECT c.oid::regclass AS table_name, c.reloptions,
2       age(c.relfrozenxid) AS xid_age
3FROM pg_class AS c
4JOIN pg_namespace AS n ON n.oid = c.relnamespace
5WHERE c.relkind IN ('r', 'm')
6  AND n.nspname NOT IN ('pg_catalog', 'information_schema')
7  AND c.reloptions IS NOT NULL
8  AND array_to_string(c.reloptions, ',')
9      ~* 'autovacuum_enabled\s*=\s*(false|off)'
10ORDER BY age(c.relfrozenxid) DESC;

关掉常规 autovacuum 后，事务 ID 防回卷的强制清理仍可能发生。找到这些表后，先查是谁设的、是否有人工维护计划，再按冻结年龄评估风险；不要把“没看到 worker”误写成 autovacuum 永远不会碰这张表。

35. 查看 autovacuum worker 是否占满名额

SQL

1SELECT current_setting('autovacuum_max_workers')::integer
2         AS configured_max_workers,
3       COUNT(*) FILTER (WHERE backend_type = 'autovacuum worker')
4         AS running_workers,
5       COUNT(*) FILTER (WHERE backend_type = 'autovacuum launcher')
6         AS running_launchers
7FROM pg_stat_activity;

几个大表长期占住 worker，其他表就可能排队。当前数量碰到上限只是线索，还要看这些 worker 具体在处理什么表、跑了多久，以及数据库间轮询；一次采样不能证明 autovacuum 长期饥饿。

人工 VACUUM 怎么控制范围

36. 只处理目标表的 TOAST 对象

SQL

1-- 第 27 条确认目标表确实存在 TOAST 对象后执行
2VACUUM (VERBOSE, PROCESS_MAIN OFF, PROCESS_TOAST ON) public.orders;

大字段频繁改写，TOAST 占用可能比表主体更值得先处理。PROCESS_MAIN OFF 跳过主表，但命令仍处理对应的 TOAST 关系；执行前看 TOAST 大小和事务边界，别因为只处理 TOAST 就认为没有 I/O 成本。

37. 强制清理目标表的死索引项

SQL

1-- 已确认死元组与索引维护问题；评估业务 I/O 窗口
2VACUUM (VERBOSE, INDEX_CLEANUP ON) public.orders;

普通 VACUUM 在死元组很少时可能跳过索引清理；ON 会尽量清理死索引项。若只是为了防回卷，PostgreSQL 的 failsafe 可能仍跳过这一步；INDEX_CLEANUP ON 不是“无论什么情况都保证索引清干净”。

38. 为多索引大表启用并行索引清理

SQL

1-- 只并行处理满足大小条件的索引，数字按可用 worker 评估
2VACUUM (VERBOSE, PARALLEL 2) public.orders;

并行 worker 用于索引清理阶段，不会把整张堆表扫描平均分给两个 worker。表至少要有两个满足条件的索引才可能启动多个 worker，还受 max_parallel_maintenance_workers 限制；命令写 2 不代表现场一定会起两个。

39. 高并发表上避免尾部截断锁

SQL

1-- 业务不能接受 VACUUM 为截断末尾空页取得 ACCESS EXCLUSIVE 锁
2VACUUM (VERBOSE, TRUNCATE OFF) public.orders;

普通 VACUUM 通常允许并发读写，但末尾空页截断需要短暂的 ACCESS EXCLUSIVE 锁。TRUNCATE OFF 放弃这一部分可能返还给文件系统的空间，换取更可控的锁行为；表内死元组回收仍照常进行。

40. 批量维护时跳过一开始就锁不上的表

SQL

1-- 逐张确认事后是否被跳过，不能只看命令整体结束
2VACUUM (VERBOSE, SKIP_LOCKED ON) public.orders, public.events;

SKIP_LOCKED 只保证开始处理某张关系时不等冲突锁；打开索引时仍可能阻塞。被跳过的表不会自动补做，下个窗口要重新检查最近 VACUUM 时间。分区表发生冲突时还可能跳过整组分区，不能把“命令成功”当成所有表都清理完。

冻结年龄高时怎么维护

41. 对接近冻结阈值的表执行积极冻结

SQL

1-- 第 10、19 条确认表及 TOAST 年龄，安排 I/O 窗口
2VACUUM (FREEZE, VERBOSE) public.orders;

FREEZE 会以更积极的方式扫描并冻结旧事务 ID，扫描成本可能明显高于普通 VACUUM。它不需要像 VACUUM FULL 那样重写整张表，但仍要先处理长期事务、复制槽等可能挡住旧版本清理的因素；不能用提高防回卷阈值代替它。

42. 冻结后回读表与 TOAST 的 XID、MXID 年龄

SQL

1SELECT c.oid::regclass AS table_name,
2       age(c.relfrozenxid) AS table_xid_age,
3       mxid_age(c.relminmxid) AS table_mxid_age,
4       CASE WHEN t.oid IS NOT NULL THEN age(t.relfrozenxid) END
5         AS toast_xid_age,
6       CASE WHEN t.oid IS NOT NULL THEN mxid_age(t.relminmxid) END
7         AS toast_mxid_age
8FROM pg_class AS c
9LEFT JOIN pg_class AS t ON t.oid = c.reltoastrelid
10WHERE c.oid = 'public.orders'::regclass;

执行前后都留一份读数。目标表的年龄降了，不代表数据库 datfrozenxid 立刻下降：同库可能还有更老的表，TOAST 也要算进去。若没有推进，结合 VERBOSE 输出、VACUUM 进度及最老事务继续排查。

43. 连续清理多张表时跳过每次更新数据库级冻结统计

SQL

1-- 同一维护流程后续会补做第 44 条；别单独执行后就停止
2VACUUM (VERBOSE, SKIP_DATABASE_STATS ON) public.orders;

数据库表非常多时，每次 VACUUM 结束都更新数据库级最老 XID 统计可能浪费时间，也会让并行维护任务争同一环节。这条只跳过该轮数据库级统计更新，不跳过目标表清理；维护结束要再刷新一次。

44. 批量清理结束后刷新数据库级冻结统计

SQL

1-- 不带表名；ONLY_DATABASE_STATS 不能与其他选项并用，VERBOSE 除外
2VACUUM (ONLY_DATABASE_STATS ON);

它不会再清理任何一张表，只更新当前数据库最老未冻结 XID 的汇总。随后回看第 9 条；如果 datfrozenxid 年龄仍高，找同库更老的表，不能把这个命令当成全库冻结。

45. 为本次 VACUUM 调整缓冲访问环大小

SQL

1-- 先看当前 vacuum_buffer_usage_limit，按缓存压力试小幅调整
2VACUUM (VERBOSE, BUFFER_USAGE_LIMIT '16MB') public.orders;

这是 VACUUM 的缓冲访问策略环，不是 maintenance_work_mem，也不代表任务只用 16 MB 内存。环过大可能挤走业务热点页；调整前后要同时看清理速度和业务缓存/读取量，不能只比较 VACUUM 完成时间。

真的要把空间还给文件系统

46. 估算表内可复用空间与重写规模

SQL

1-- 当前库已安装 pgstattuple；结果只是维护前估算
2SELECT pg_relation_size('public.orders'::regclass) AS heap_bytes,
3       pg_total_relation_size('public.orders'::regclass) AS total_bytes,
4       a.dead_tuple_percent, a.approx_free_percent,
5       a.approx_free_space
6FROM pgstattuple_approx('public.orders'::regclass) AS a;

要从文件系统拿回空间，先分清表主体、索引和 TOAST 哪一部分大。approx_free_space 是表内可复用空间估计，不等于 VACUUM FULL 一定能返还的字节数；重写期间还需要放下新文件，现场磁盘余量必须从服务器上另查。

47. 查看目标表当前持有哪些关系锁

SQL

1SELECT l.pid, l.mode, l.granted,
2       a.state, a.xact_start,
3       now() - a.xact_start AS xact_age,
4       left(a.query, 120) AS query_sample
5FROM pg_locks AS l
6LEFT JOIN pg_stat_activity AS a ON a.pid = l.pid
7WHERE l.locktype = 'relation'
8  AND l.relation = 'public.orders'::regclass
9ORDER BY l.granted DESC, a.xact_start NULLS LAST;

VACUUM FULL 要拿 ACCESS EXCLUSIVE 锁，读写都会被挡住。开工前除了看眼前的持锁会话，还要确认业务是否会不断产生新事务；一次锁快照不能保证维护时一定马上拿到锁。

48. 在确认停机窗口和磁盘余量后重写目标表

SQL

1-- 已确认 ACCESS EXCLUSIVE 锁影响、额外磁盘、回退及复制延迟
2VACUUM (FULL, VERBOSE) public.orders;

这条会重写整张表并重建相关索引，通常比普通 VACUUM 慢得多，过程中持续持有 ACCESS EXCLUSIVE 锁。只有明确需要回收文件系统空间、且业务能接受停写停读时才考虑；它不是表增长后的默认维护动作。

49. 查看 VACUUM FULL 正在重写到哪一步

SQL

1SELECT pid, relid::regclass AS table_name,
2       command, phase, heap_blks_total,
3       heap_blks_scanned, heap_tuples_written,
4       index_rebuild_count
5FROM pg_stat_progress_cluster
6WHERE command = 'VACUUM FULL';

VACUUM FULL 不出现在普通 VACUUM 的进度视图里。扫描、写新堆、交换文件、重建索引是不同阶段；扫描完成不表示锁可以释放，也不表示索引已重建完。结合磁盘 I/O 和等待事件判断是否真正卡住。

50. 重写后回读表大小与文件节点

SQL

1SELECT 'public.orders'::regclass AS table_name,
2       pg_relation_size('public.orders'::regclass) AS heap_bytes,
3       pg_total_relation_size('public.orders'::regclass) AS total_bytes,
4       pg_relation_filenode('public.orders'::regclass) AS current_filenode;

用第 46 条留存的维护前大小比较，别只看 VACUUM FULL 返回成功。表文件节点可能换过，旧路径上的文件不会继续代表这张表；空间回收验收还要看服务器文件系统余量，以及业务查询、复制是否恢复正常。

只重建索引，别把整张表锁住

51. 对照目标表各索引大小与扫描次数

SQL

1SELECT i.indexrelid::regclass AS index_name,
2       pg_relation_size(i.indexrelid) AS index_bytes,
3       s.idx_scan, s.last_idx_scan
4FROM pg_index AS i
5LEFT JOIN pg_stat_user_indexes AS s
6  ON s.indexrelid = i.indexrelid
7WHERE i.indrelid = 'public.orders'::regclass
8ORDER BY index_bytes DESC;

索引大而扫描次数少，不代表它没用：约束索引和写入路径仍可能需要它，统计计数也可能刚被重置。要重建哪个索引，先结合第 25 条页密度、业务查询和增长趋势挑目标，不要对整张表所有索引一键重建。

52. 核对待重建索引的类型和有效状态

SQL

1SELECT i.indexrelid::regclass AS index_name,
2       am.amname AS access_method,
3       i.indisunique, i.indisexclusion,
4       i.indisvalid, i.indisready
5FROM pg_index AS i
6JOIN pg_class AS c ON c.oid = i.indexrelid
7JOIN pg_am AS am ON am.oid = c.relam
8WHERE i.indexrelid = 'public.orders_pkey'::regclass;

REINDEX CONCURRENTLY 对排他约束索引有限制；如果目标索引已经无效，先确认它是失败后的 _ccnew 临时索引，还是原索引自身出问题。indisvalid、indisready 影响查询和写入，不能只凭索引文件还在就判断它可用。

53. 在线重建一条确定需要处理的索引

SQL

1-- 评估新旧索引并存的磁盘空间、长事务与业务 I/O
2REINDEX INDEX CONCURRENTLY public.orders_pkey;

在线重建允许表继续正常读写，但比普通 REINDEX 更慢，也需要新旧索引同时占用磁盘；它不能放在事务块中。对同一张表不能并行开多个 concurrent index build，执行期间要监控长事务与复制延迟。

54. 查看在线重建正在等哪一阶段

SQL

1SELECT pid, relid::regclass AS table_name,
2       index_relid::regclass AS index_name,
3       command, phase, blocks_total, blocks_done,
4       lockers_total, lockers_done, current_locker_pid
5FROM pg_stat_progress_create_index
6WHERE command = 'REINDEX CONCURRENTLY';

进度可能长时间停在等待旧事务或快照的阶段；这时 current_locker_pid 比扫描百分比更有用。先找到对应业务事务，别看到进度不动就直接取消任务；取消后可能留下需要处理的无效临时索引。

55. 重建后核对索引有效性与大小

SQL

1SELECT i.indexrelid::regclass AS index_name,
2       i.indisvalid, i.indisready,
3       pg_relation_size(i.indexrelid) AS index_bytes
4FROM pg_index AS i
5WHERE i.indrelid = 'public.orders'::regclass
6ORDER BY index_bytes DESC;

与第 51 条维护前大小对比，同时确认原目标索引处于有效状态。若发现 _ccnew 或 _ccold 无效索引，先按官方恢复步骤识别它的角色，再决定清理；不要看到无效就把原业务索引删掉。

分区父表的统计信息要单独照看

56. 找出很久没有人工 ANALYZE 的分区父表

SQL

1SELECT c.oid::regclass AS parent_table,
2       COUNT(i.inhrelid) AS direct_children,
3       s.last_analyze, s.last_autoanalyze
4FROM pg_class AS c
5LEFT JOIN pg_inherits AS i ON i.inhparent = c.oid
6LEFT JOIN pg_stat_user_tables AS s ON s.relid = c.oid
7WHERE c.relkind = 'p'
8GROUP BY c.oid, s.last_analyze, s.last_autoanalyze
9ORDER BY s.last_analyze NULLS FIRST, direct_children DESC;

分区父表自己不存行，autovacuum 会处理叶子分区，却不会自动给分区父表做 ANALYZE。父表长期没有人工统计更新时，规划器处理整棵分区树可能使用旧分布。这里只数直接子分区，多级分区要继续向下查。

57. 对照父表下各直接分区的清理时间与死元组

SQL

1SELECT i.inhrelid::regclass AS child_partition,
2       c.relkind, s.n_dead_tup,
3       s.last_autovacuum, s.last_autoanalyze,
4       pg_total_relation_size(i.inhrelid) AS total_bytes
5FROM pg_inherits AS i
6JOIN pg_class AS c ON c.oid = i.inhrelid
7LEFT JOIN pg_stat_user_tables AS s ON s.relid = i.inhrelid
8WHERE i.inhparent = 'public.orders_partitioned'::regclass
9ORDER BY total_bytes DESC;

父表没被 autovacuum 处理，不等于子分区也没清理。先找到增长快或死元组多的叶子分区，再核对对应的 autovacuum；这里显示直接子节点，若 relkind='p'，它下面还有一层要查。

58. 查看父表统计是否包含分区数据

SQL

1SELECT schemaname, tablename, attname,
2       inherited, null_frac, n_distinct
3FROM pg_stats
4WHERE schemaname = 'public'
5  AND tablename = 'orders_partitioned'
6ORDER BY inherited DESC, attname;

inherited=true 表示这一组列统计包含子分区数据。缺行时先确认是否还没跑过 ANALYZE、当前账号能否读取统计视图；也别只看统计行“存在”就认定它仍适合今天的参数分布。

59. 手工更新分区父表与子分区统计

SQL

1-- 分区分布明显变化后执行；在目标数据库操作
2ANALYZE (VERBOSE) public.orders_partitioned;

PostgreSQL 会从分区采样，建立父表覆盖分区的数据统计，并递归更新各分区。它不是 VACUUM，不会清死元组；业务高峰仍要评估采样 I/O 和对其他维护任务的锁影响。

60. 查看分区父表 ANALYZE 的采样进度

SQL

1SELECT pid, relid::regclass AS table_name,
2       phase, sample_blks_total, sample_blks_scanned,
3       child_tables_total, child_tables_done,
4       current_child_table_relid::regclass AS current_child
5FROM pg_stat_progress_analyze
6WHERE relid = 'public.orders_partitioned'::regclass;

acquiring inherited sample rows 阶段可看到正在处理哪个子分区；最后还会计算统计并写入目录。进度行消失只表示该任务结束，是否成功、父表统计有没有更新时间，应继续看命令返回与 pg_stat_user_tables.last_analyze。

index-only scan 仍回表时看可见性映射

61. 确认当前库已安装 pg_visibility

SQL

1SELECT extname, extversion,
2       extnamespace::regnamespace AS extension_schema
3FROM pg_extension
4WHERE extname = 'pg_visibility';

后面的 pg_visibility_map_summary 来自这个扩展。没安装就不能直接运行；安装扩展是数据库变更，先走现场维护流程。不要为了看一个指标，未经确认就在线上新装模块。

62. 统计目标表 all-visible 与 all-frozen 页比例

SQL

1-- 当前库已安装 pg_visibility；比例以堆表主文件页数为分母
2SELECT v.all_visible, v.all_frozen,
3       pg_relation_size('public.orders'::regclass)
4         / current_setting('block_size')::bigint AS heap_pages,
5       ROUND(v.all_visible * 100.0 / NULLIF(
6           pg_relation_size('public.orders'::regclass)
7             / current_setting('block_size')::bigint, 0), 1)
8         AS all_visible_percent
9FROM pg_visibility_map_summary('public.orders'::regclass) AS v;

all-visible 页多，index-only scan 才更有机会少访问堆表；all-frozen 页则影响下一轮冻结扫描。页面被 UPDATE、DELETE 或 INSERT 改动后，映射位会清掉，单次高比例并不保证业务查询始终不回表。

63. 在实际查询计划里看 Heap Fetches

SQL

1-- 只对可控的 SELECT 样例执行；范围替换为业务参数
2EXPLAIN (ANALYZE, BUFFERS)
3SELECT order_id
4FROM public.orders
5WHERE order_id BETWEEN 100000 AND 101000;

如果计划用了 Index Only Scan，再看 Heap Fetches 是否仍高；有这个节点也不表示完全没读堆页。若计划根本没用 index-only scan，先确认索引是否覆盖查询所需列、成本估计是否合适，再讨论可见性映射。ANALYZE 会真的执行 SELECT，不应拿不受控的大查询直接试。

64. 抽样查看慢查询命中的堆页映射位

SQL

1-- 当前库已安装 pg_visibility；只取少量命中行的页号
2WITH sampled_pages AS (
3    SELECT DISTINCT split_part(trim(both '()' FROM ctid::text), ',', 1)::bigint
4      AS blkno
5    FROM public.orders
6    WHERE order_id BETWEEN 100000 AND 101000
7    LIMIT 20
8)
9SELECT s.blkno, v.all_visible, v.all_frozen
10FROM sampled_pages AS s
11CROSS JOIN LATERAL pg_visibility_map(
12    'public.orders'::regclass, s.blkno) AS v
13ORDER BY s.blkno;

这只抽样检查查询命中的部分堆页，不是全表扫描结论。大量抽样页都不 all-visible 时，index-only scan 仍要回表核对可见性；还要结合更新速率与最近 VACUUM 时间，不能凭 20 个页号判定整表映射有问题。

65. 回读表更新量与最近 VACUUM 时间

SQL

1SELECT relid::regclass AS table_name,
2       n_dead_tup, n_ins_since_vacuum,
3       n_tup_upd, n_tup_del,
4       last_vacuum, last_autovacuum
5FROM pg_stat_user_tables
6WHERE relid = 'public.orders'::regclass;

n_tup_upd、n_tup_del 是累计计数，不是“上次 VACUUM 后的更新数”；读数高时要看两次采样的差值。频繁改动会反复清除 all-visible 位，普通 VACUUM 跑过也未必能让这类热点表长期保持 index-only scan 的低 Heap Fetches。

UPDATE 多的表，先看 HOT 比例

66. 统计目标表 HOT 更新占比

SQL

1SELECT relid::regclass AS table_name,
2       n_tup_upd, n_tup_hot_upd,
3       ROUND(n_tup_hot_upd * 100.0 / NULLIF(n_tup_upd, 0), 1)
4         AS hot_update_percent
5FROM pg_stat_user_tables
6WHERE relid = 'public.orders'::regclass;

HOT 更新无需为常规索引写入新的索引项，能减轻更新引起的索引负担。比例低时先看哪些列被更新、这些列是否被索引引用，以及原页有没有空间；累计比例会掩盖最近变化，最好留两次采样比较增量。

67. 查有多少更新把新行版本放到了别的页

SQL

1SELECT relid::regclass AS table_name,
2       n_tup_upd, n_tup_newpage_upd,
3       ROUND(n_tup_newpage_upd * 100.0 / NULLIF(n_tup_upd, 0), 1)
4         AS moved_to_new_page_percent
5FROM pg_stat_user_tables
6WHERE relid = 'public.orders'::regclass;

新版本落在别的堆页就不是 HOT 更新。这个比例高时，页内余量和行宽变化值得查；但统计只告诉你发生了跨页更新，不会告诉你具体是哪一列变长或哪个索引阻止 HOT。

68. 列出目标表的索引定义

SQL

1SELECT i.indexrelid::regclass AS index_name,
2       pg_get_indexdef(i.indexrelid) AS index_definition
3FROM pg_index AS i
4WHERE i.indrelid = 'public.orders'::regclass
5ORDER BY i.indexrelid::regclass::text;

应用经常修改的列若参与普通索引，HOT 条件可能不成立；表达式索引和 INCLUDE 列也要看。这里先把定义列出来交给开发核对更新语句，不能只凭 HOT 比例低就建议删除索引。

69. 查看表当前 fillfactor 与空闲空间

SQL

1-- 当前库已安装 pgstattuple；reloptions 为 NULL 通常使用默认值
2SELECT c.oid::regclass AS table_name, c.reloptions,
3       a.approx_free_percent, a.scanned_percent
4FROM pg_class AS c
5CROSS JOIN LATERAL pgstattuple_approx(c.oid::regclass) AS a
6WHERE c.oid = 'public.orders'::regclass;

降低 fillfactor 能在新页预留更多更新空间，但已有页不会因为改参数就立即腾出余量。先结合真实写入模式与空闲空间估计，别把所有低 HOT 比例都归因于 fillfactor；索引列被修改时，留空也不能产生 HOT。

70. 评估后降低目标表的 fillfactor

SQL

1-- 仅在确认更新模式、额外空间成本和维护窗口后执行
2ALTER TABLE public.orders SET (fillfactor = 80);

80 是示例，降低 fillfactor 会增加表占用空间，换取后续同页更新的机会。修改表存储参数会取 SHARE UPDATE EXCLUSIVE 锁；现有页不会立刻重排，不能把执行成功当成 HOT 比例马上提高。后续按第 66、67 条看增量是否改善。

autovacuum 跑得慢，先看限速与内存

71. 核对清理限速和每个 worker 的工作内存

SQL

1SELECT name, setting, unit, source
2FROM pg_settings
3WHERE name IN ('autovacuum_vacuum_cost_delay',
4               'autovacuum_vacuum_cost_limit',
5               'vacuum_cost_delay', 'vacuum_cost_limit',
6               'autovacuum_work_mem', 'maintenance_work_mem',
7               'autovacuum_max_workers')
8ORDER BY name;

人工 VACUUM 默认通常不做成本限速，autovacuum 则可能主动睡眠以压低 I/O。autovacuum_work_mem=-1 表示使用 maintenance_work_mem；估算内存时还要乘可能同时工作的 worker 数，不能只看单进程配置。

72. 抽样确认 worker 是否在 VacuumDelay

SQL

1SELECT a.pid, p.relid::regclass AS table_name,
2       now() - a.query_start AS run_time,
3       p.phase, a.wait_event_type, a.wait_event
4FROM pg_stat_activity AS a
5JOIN pg_stat_progress_vacuum AS p ON p.pid = a.pid
6WHERE a.backend_type = 'autovacuum worker'
7ORDER BY a.query_start;

VacuumDelay 是成本限速的一次正常休眠，不是“任务死锁”；但如果 worker 长时间占着表且进度慢，就要看限速是否过严、表写入是否持续追不上。等待事件是瞬时采样，两次进度对比比一次截图更可靠。

73. 看死元组缓冲是否逼出多轮索引清理

SQL

1SELECT relid::regclass AS table_name, phase,
2       dead_tuple_bytes, max_dead_tuple_bytes,
3       index_vacuum_count,
4       ROUND(dead_tuple_bytes * 100.0
5             / NULLIF(max_dead_tuple_bytes, 0), 1)
6         AS dead_buffer_percent
7FROM pg_stat_progress_vacuum
8ORDER BY index_vacuum_count DESC, dead_buffer_percent DESC;

死元组缓冲反复接近上限、索引清理轮数不断增长时，核对第 71 条的 worker 内存和第 12 条索引阶段。调大内存不是唯一答案：表更新过快、索引过多也会增加工作量，而且每个 worker 都可能申请自己的内存。

74. 找出表级清理限速的覆盖设置

SQL

1SELECT c.oid::regclass AS table_name,
2       option AS table_setting
3FROM pg_class AS c
4CROSS JOIN LATERAL unnest(c.reloptions) AS option
5WHERE c.relkind IN ('r', 'm')
6  AND option ~ '^autovacuum_vacuum_cost_(delay|limit)='
7ORDER BY table_name, table_setting;

有表级 cost delay/limit 时，该 worker 不一定参与全局 worker 的成本均衡。现场同样的全局参数，不同表的运行速度可能差很多；先找出覆盖设置，再解释它为何被单独限速。

75. 核对 autovacuum 的日志阈值

SQL

1SELECT name, setting, unit, source
2FROM pg_settings
3WHERE name IN ('log_autovacuum_min_duration',
4               'log_destination', 'logging_collector')
5ORDER BY name;

没有 autovacuum 日志，不能直接认定任务没运行：可能是阈值设得太高，或日志写在另一个目标。需要追“为什么被取消”“清了多少页”时，先确认日志是否开启、去哪里查，再结合统计视图的最近运行时间。

大表别等默认比例攒满死元组

76. 找出超过全局触发门槛、没有表级设置的表

SQL

1SELECT c.oid::regclass AS table_name,
2       c.reltuples AS estimated_rows, s.n_dead_tup,
3       current_setting('autovacuum_vacuum_threshold')::numeric
4       + current_setting('autovacuum_vacuum_scale_factor')::numeric
5         * GREATEST(c.reltuples, 0) AS global_trigger_rows,
6       s.last_autovacuum
7FROM pg_class AS c
8JOIN pg_stat_user_tables AS s ON s.relid = c.oid
9WHERE c.relkind = 'r' AND c.reloptions IS NULL
10  AND s.n_dead_tup >
11      current_setting('autovacuum_vacuum_threshold')::numeric
12      + current_setting('autovacuum_vacuum_scale_factor')::numeric
13        * GREATEST(c.reltuples, 0)
14ORDER BY s.n_dead_tup DESC
15LIMIT 30;

只列 reloptions 为空的普通表，避免拿全局公式错算特殊表；仅设置了 fillfactor 等其他参数的表也会被这条排除，要另查第 77 条。跨过门槛说明它应有机会被调度，不表示 worker 一定马上空出来；再结合运行中任务、日志和最近清理时间判断有没有排队。

77. 按表级覆盖设置计算目标表的有效门槛

SQL

1SELECT c.oid::regclass AS table_name, s.n_dead_tup,
2       COALESCE((SELECT split_part(opt, '=', 2)::numeric
3                 FROM unnest(c.reloptions) AS opt
4                 WHERE split_part(opt, '=', 1) =
5                       'autovacuum_vacuum_threshold' LIMIT 1),
6                current_setting('autovacuum_vacuum_threshold')::numeric)
7       + COALESCE((SELECT split_part(opt, '=', 2)::numeric
8                   FROM unnest(c.reloptions) AS opt
9                   WHERE split_part(opt, '=', 1) =
10                         'autovacuum_vacuum_scale_factor' LIMIT 1),
11                  current_setting('autovacuum_vacuum_scale_factor')::numeric)
12         * GREATEST(c.reltuples, 0) AS effective_trigger_rows
13FROM pg_class AS c
14JOIN pg_stat_user_tables AS s ON s.relid = c.oid
15WHERE c.oid = 'public.orders'::regclass;

第 31 条只按全局参数估算；这一条先找表级值，没有才回退全局值。reltuples 和死元组数仍是估计数。若目标表明确关闭常规 autovacuum，跨过普通门槛也不会按常规方式调度，但防回卷强制清理另算。

78. 核对 autovacuum 的基础开关和轮询周期

SQL

1SELECT name, setting, unit, source
2FROM pg_settings
3WHERE name IN ('autovacuum', 'track_counts',
4               'autovacuum_naptime', 'autovacuum_max_workers')
5ORDER BY name;

autovacuum 依赖累计统计系统，track_counts 关了就不能按正常统计触发。autovacuum_naptime 是轮询间隔，不是每张表精确多久清一次；数据库多、worker 忙时，实际等待可能更长。

79. 为更新频繁的大表缩小清理和分析比例

SQL

1-- 先计算旧门槛，评估 worker I/O 与业务窗口
2ALTER TABLE public.orders SET (
3    autovacuum_vacuum_scale_factor = 0.02,
4    autovacuum_analyze_scale_factor = 0.01
5);

这两个比例是示例，应该按表大小、更新速率和 I/O 能力定。阈值降低，任务可能更频繁，不能只看死元组下降就宣布配置更好；业务读取、日志和 worker 排队也要一起观察。修改表存储参数需要短暂锁，先确认现场变更窗口。

80. 回读表级设置与下一轮清理结果

SQL

1SELECT c.oid::regclass AS table_name, c.reloptions,
2       s.n_dead_tup, s.n_mod_since_analyze,
3       s.last_autovacuum, s.last_autoanalyze,
4       s.autovacuum_count, s.autoanalyze_count
5FROM pg_class AS c
6JOIN pg_stat_user_tables AS s ON s.relid = c.oid
7WHERE c.oid = 'public.orders'::regclass;

先确认参数确实写在目标表上，再等下一轮 worker 运行后比较死元组、统计更新时间和业务负载。计数可能被统计重置，时间戳也不会因为改参数立刻更新；“回读配置成功”与“调优见效”是两回事。

临时表不能等 autovacuum

81. 列出当前会话创建的临时表

SQL

1SELECT c.oid::regclass AS temp_table,
2       c.relpersistence, c.reltuples,
3       pg_total_relation_size(c.oid) AS total_bytes
4FROM pg_class AS c
5WHERE c.relnamespace = pg_my_temp_schema()
6  AND c.relkind = 'r'
7ORDER BY total_bytes DESC;

pg_my_temp_schema() 只指向当前会话的临时模式，没有临时表时返回零。临时表由创建它的会话使用，autovacuum 无法跨会话替它清理或分析；不要在另一个 DBA 连接里找到了名字，就以为能维护业务会话里的对象。

82. 看当前会话临时表的统计与维护时间

SQL

1SELECT s.relid::regclass AS temp_table,
2       s.n_live_tup, s.n_dead_tup,
3       s.last_vacuum, s.last_analyze,
4       s.vacuum_count, s.analyze_count
5FROM pg_stat_all_tables AS s
6JOIN pg_class AS c ON c.oid = s.relid
7WHERE c.relnamespace = pg_my_temp_schema()
8  AND c.relkind = 'r'
9ORDER BY s.n_dead_tup DESC;

会话内重复装载、更新临时表时，死元组和统计信息也可能变旧。统计读数有延迟；任务若每次都创建后立即丢弃临时表，人工 VACUUM 通常没有意义，但复杂查询前的 ANALYZE 仍可能有价值。

83. 在持有临时表的会话内执行普通 VACUUM

SQL

1-- 当前会话持有并重复使用这张临时表；不能放进事务块
2VACUUM (VERBOSE) pg_temp.session_stage;

临时表复用多轮且有大量 UPDATE/DELETE 时，自己安排维护；别指望后台 autovacuum。pg_temp 解析到本会话的临时模式，换一个连接不会维护原会话那张表。先确认会话事务流程允许独立执行 VACUUM。

84. 临时表装载后主动更新规划器统计

SQL

1-- 数据量或分布明显变化、且后续有复杂连接查询
2ANALYZE pg_temp.session_stage;

临时表没有自动 ANALYZE，旧估计很容易让后续 JOIN 选错方法。刚装入大批数据后手工分析通常比只看 reltuples 更可靠；这一条只更新统计，不会回收死元组。

85. 回读临时表列统计是否已生成

SQL

1SELECT schemaname, tablename, attname,
2       null_frac, n_distinct, most_common_freqs
3FROM pg_stats
4WHERE schemaname = (
5    SELECT nspname FROM pg_namespace
6    WHERE oid = pg_my_temp_schema())
7  AND tablename = 'session_stage'
8ORDER BY attname;

统计行存在，说明目标会话已有可供规划器参考的列分布；但这不是计划一定变好的证明。继续用真实业务 SQL 的 EXPLAIN 看行数估计和连接方法，尤其注意数据装载后的再次变化。

物化视图刷新后还要看空间

86. 列出物化视图的占用与可查询状态

SQL

1SELECT m.schemaname, m.matviewname, m.ispopulated,
2       m.hasindexes,
3       pg_total_relation_size(
4           format('%I.%I', m.schemaname, m.matviewname)::regclass)
5         AS total_bytes
6FROM pg_matviews AS m
7ORDER BY total_bytes DESC;

ispopulated=false 的物化视图当前不能被正常查询，也不能做 concurrent refresh。总大小包含索引和可能的 TOAST；先找到真正占空间的对象，再看它的刷新方式与最近维护时间。

87. 确认目标物化视图有可用的全行唯一索引

SQL

1SELECT i.indexrelid::regclass AS index_name,
2       i.indisunique, i.indisvalid, i.indisready,
3       i.indexprs IS NULL AS no_expression,
4       i.indpred IS NULL AS no_partial_predicate
5FROM pg_index AS i
6WHERE i.indrelid = 'public.daily_orders_mv'::regclass
7ORDER BY i.indisunique DESC, i.indexrelid::regclass::text;

REFRESH MATERIALIZED VIEW CONCURRENTLY 至少需要一条只基于列、覆盖所有行的 UNIQUE 索引，且物化视图已填充。这里把候选索引筛出来，还要核对索引定义和状态；不能把 hasindexes=true 当成 concurrent refresh 的充分条件。

88. 在具备条件时并发刷新物化视图

SQL

1-- 第 86、87 条均通过；确认源查询、磁盘与业务负载
2REFRESH MATERIALIZED VIEW CONCURRENTLY public.daily_orders_mv;

并发刷新允许读者继续查询旧内容，且同一物化视图一次只能运行一个刷新任务。它通常比普通刷新做更多工作；源数据变化较大时，刷新后的旧版本与空间占用值得继续查。普通刷新可能直接替换内容，两种刷新不能用相同的空间预期验收。

89. 刷新后检查死元组、大小和最近维护时间

SQL

1SELECT c.oid::regclass AS matview_name,
2       pg_total_relation_size(c.oid) AS total_bytes,
3       s.n_live_tup, s.n_dead_tup,
4       s.last_autovacuum, s.last_autoanalyze
5FROM pg_class AS c
6LEFT JOIN pg_stat_user_tables AS s ON s.relid = c.oid
7WHERE c.oid = 'public.daily_orders_mv'::regclass
8  AND c.relkind = 'm';

并发刷新之后若死元组仍多，结合更新量、长事务和 autovacuum 再决定是否人工清理。统计列为空时先确认目标对象是否被统计视图收录以及读取权限。n_dead_tup 是估计数；视图文件变大也可能主要来自索引，不能把刷新后每一字节增长都叫“表膨胀”。

90. 确有清理需求时维护物化视图

SQL

1-- 确认刷新已结束、源查询稳定、目标视图可维护
2VACUUM (VERBOSE, ANALYZE) public.daily_orders_mv;

普通 VACUUM 可回收物化视图里的可复用空间，ANALYZE 更新供查询使用的统计；多数空间仍留在对象内复用，不保证文件系统马上减少。若刚做的是整表替换式刷新，先看第 89 条，别无条件再补一轮 VACUUM。

防回卷风险与维护验收

91. 检查各数据库的 MultiXact 年龄

SQL

1SELECT datname, mxid_age(datminmxid) AS mxid_age,
2       current_setting('autovacuum_multixact_freeze_max_age')::bigint
3         AS multixact_freeze_limit
4FROM pg_database
5WHERE datallowconn
6ORDER BY mxid_age DESC;

行锁和外键检查可能产生 MultiXact。它与普通事务 ID 分开计龄；第 9 条只看 datfrozenxid，不能代替这一条。最老的库若已接近阈值，进库找表和 TOAST 的 relminmxid，同时检查自动维护有没有被长事务挡住。

92. 找出 MultiXact 年龄最高的关系

SQL

1SELECT c.oid::regclass AS relation,
2       c.relkind, mxid_age(c.relminmxid) AS mxid_age,
3       pg_total_relation_size(c.oid) AS total_bytes
4FROM pg_class AS c
5WHERE c.relkind IN ('r', 't', 'm')
6ORDER BY mxid_age DESC
7LIMIT 30;

在第 91 条提示的数据库内执行。t 是 TOAST 表，不能只维护业务表而漏掉它；relminmxid 接近阈值时，再看目标对象正在运行的 VACUUM 和持有旧快照的会话。排序只用于定位，不是“前 30 张表都要立即手工冻结”的任务单。

93. 确认防回卷 autovacuum 是否正在运行

SQL

1SELECT a.pid, a.datname, a.query,
2       p.relid::regclass AS relation,
3       p.phase, p.heap_blks_scanned, p.heap_blks_total
4FROM pg_stat_activity AS a
5LEFT JOIN pg_stat_progress_vacuum AS p ON p.pid = a.pid
6WHERE a.backend_type = 'autovacuum worker'
7  AND a.query LIKE '%to prevent wraparound%'
8ORDER BY a.pid;

防回卷 worker 的活动描述会标出 to prevent wraparound。查询为空不等于风险消失：可能尚未触发、刚结束，或只因权限看不到完整活动文本。先对照第 91、92 条的年龄和普通 autovacuum 运行情况，再判断是否需要人工介入。

94. 核对冻结和 failsafe 阈值

SQL

1SELECT name, setting, unit, source
2FROM pg_settings
3WHERE name IN (
4    'autovacuum_freeze_max_age',
5    'autovacuum_multixact_freeze_max_age',
6    'vacuum_failsafe_age',
7    'vacuum_multixact_failsafe_age')
8ORDER BY name;

autovacuum_*_freeze_max_age 决定何时强制防回卷维护；failsafe 年龄更高，触发后 VACUUM 会优先推进冻结，可能跳过非必要的索引清理并放宽限速。不要把 failsafe 当成日常清理策略。改阈值前应同时核对磁盘、维护吞吐和最老关系的年龄。

95. 看本库还有多少冻结年龄余量

SQL

1SELECT d.datname,
2       age(d.datfrozenxid) AS xid_age,
3       current_setting('autovacuum_freeze_max_age')::bigint
4         - age(d.datfrozenxid) AS xid_headroom,
5       mxid_age(d.datminmxid) AS mxid_age,
6       current_setting('autovacuum_multixact_freeze_max_age')::bigint
7         - mxid_age(d.datminmxid) AS mxid_headroom
8FROM pg_database AS d
9WHERE d.datname = current_database();

余量为负说明已经越过自动维护触发阈值，不是事务 ID 已经回卷。数据库级读数还取决于其他表是否已冻结；维护一张表后没有立即下降，要回到第 91、92 条找仍然最老的对象，并看第 93 条 worker 是否推进。

96. 对最老关系做冻结维护

SQL

1-- 确认最老关系、长事务和业务窗口；在目标数据库独立执行
2VACUUM (FREEZE, VERBOSE) public.orders_history;

第 41 条是普通目标表冻结示例；这一条针对第 92、95 条已经确认的防回卷对象。FREEZE 会积极冻结该表符合条件的旧事务版本，但不能越过仍被长事务需要的可见性边界。运行时看 VERBOSE 与进度，结束后分别回读表和数据库年龄；TOAST 或其他表仍老时还要继续定位。

97. 查并发重建后留下的无效索引

SQL

1SELECT t.oid::regclass AS table_name,
2       x.oid::regclass AS index_name,
3       i.indisvalid, i.indisready,
4       pg_relation_size(x.oid) AS index_bytes
5FROM pg_index AS i
6JOIN pg_class AS x ON x.oid = i.indexrelid
7JOIN pg_class AS t ON t.oid = i.indrelid
8WHERE NOT i.indisvalid
9  AND t.relkind IN ('r', 'm')
10ORDER BY index_bytes DESC;

REINDEX CONCURRENTLY 失败可能留下 _ccnew 或 _ccold，它们会占空间，部分状态下还可能拖累写入。先按索引定义、命名和 indisready 确认是哪一步留下的对象；普通无效业务索引不能按后缀规则直接删除。清理前保存 DDL，并按官方的失败恢复步骤处理。

98. 对照目标表维护前后的时间与死元组估计

SQL

1SELECT s.relid::regclass AS relation,
2       s.last_vacuum, s.last_autovacuum,
3       s.vacuum_count, s.autovacuum_count,
4       s.n_live_tup, s.n_dead_tup,
5       s.n_mod_since_analyze
6FROM pg_stat_user_tables AS s
7WHERE s.relid = 'public.orders_history'::regclass;

维护时间和计数用于确认工作确实落在目标表；死元组数是估计值，统计有延迟，还可能被重置。若 n_mod_since_analyze 很高，规划器估计仍可能过时，可按第 30 条补 ANALYZE。不要只凭 n_dead_tup 降到零就宣布问题解决。

99. 对照目标表的冻结年龄与文件大小

SQL

1SELECT c.oid::regclass AS relation,
2       age(c.relfrozenxid) AS xid_age,
3       mxid_age(c.relminmxid) AS mxid_age,
4       pg_relation_size(c.oid) AS heap_bytes,
5       pg_indexes_size(c.oid) AS indexes_bytes
6FROM pg_class AS c
7WHERE c.oid = 'public.orders_history'::regclass;

把这组读数与维护前同口径快照对照。普通 VACUUM 后冻结年龄可能明显下降，但 heap 文件未缩小，这并不矛盾：空间通常在表内复用。若索引大小持续涨、死元组已少，回到第 51–55 条判断是否有独立的索引膨胀问题。

100. 检查数据库汇总年龄是否推进

SQL

1SELECT current_database() AS database_name,
2       age(d.datfrozenxid) AS oldest_xid_age,
3       mxid_age(d.datminmxid) AS oldest_mxid_age,
4       d.datfrozenxid, d.datminmxid
5FROM pg_database AS d
6WHERE d.datname = current_database();

这是防回卷维护的最后一层回读，不是要求两个数字每次都下降。一张表处理完，本库最老边界可能仍落在别的表或 TOAST 上；按第 91、92 条再查。验收时还要把第 98、99 条、VACUUM 输出、业务负载和无效索引清单放在一起看。

总结

排查 VACUUM，先分清是死元组清理慢、旧快照挡住了回收，还是冻结年龄真的接近阈值。普通 VACUUM 清出的空间通常留在表里复用；要缩小文件，得另算锁和磁盘成本。维护结束，把表、索引与数据库级年龄各回读一次，比看一条“命令完成”更稳妥。

这份清单建议收藏。其他数据库运维场景的命令可在 ORA100 · DBA100 查看：

https://ora100.com/dba100

微信里也可以搜索小程序 「三笠的百令册」，需要时按专题查。

PostgreSQL 表膨胀与索引维护 100 条命令 - DBA 学习之路