PostgreSQL 19 深度解析：从零停机 REPACK 到「自治 Vacuum」，PostgreSQL 的运维范式革命

每一个把 PostgreSQL 跑在生产环境的团队，几乎都经历过同一种深夜告警：某张核心表膨胀到原来的 3 倍，查询开始变慢，而你不得不排期一次 VACUUM FULL 或 pg_repack，在业务低峰期硬着头皮停机维护。PostgreSQL 19 这次没有挤牙膏，而是把三件 DBA 最头疼的事一次性端了：零停机重建、并行自动清理、以及首次出现的「优先级自动清理」。本文从底层原理讲起，带你把这三个特性真正用明白。

一、背景：每一个 PostgreSQL DBA 都熬过的夜

PostgreSQL 之所以能在 2026 年稳坐开源关系型数据库头把交椅，靠的不是某个炫酷特性，而是它的稳定性与可预测性。但稳定是有代价的——这个代价叫 MVCC。

多版本并发控制（Multi-Version Concurrency Control）让读写互不阻塞，这是 PostgreSQL 高并发能力的根基。但它的副作用是：任何一次 UPDATE 或 DELETE，旧版本的行并不会立即物理删除，而是被标记成「死元组」（dead tuple）。这些死元组占着磁盘、拖慢扫描、让索引越来越肥。

清理死元组的职责落在 VACUUM 和后台的 autovacuum 身上。理论上这套机制能自愈，但在真实生产里，下面三件事总会把 DBA 逼到半夜：

1. 表膨胀（bloat）失控：高写入量表如果 autovacuum 跟不上，死元组越积越多，表文件膨胀到数倍，查询计划被拖垮。
2. autovacuum 调优是个玄学：默认参数偏向「不打扰业务」，结果大表永远清不干净；调激进一点又怕吃满 IO。
3. 重建索引/表必须停机：想彻底瘦身，过去只有 VACUUM FULL（拿 ACCESS EXCLUSIVE 锁，表完全不可写）或者依赖 pg_repack 扩展——而扩展本身又要单独安装、单独排期、单独兜底。

PostgreSQL 19 的答案很干脆：把「运维动作」下沉成数据库内建能力，并且默认就对业务友好。下面我们先把病根讲透，再看 19 到底怎么治。

二、核心概念：先把「病根」讲清楚

2.1 MVCC 与死元组（dead tuples）

PostgreSQL 的每一行都带着两个系统字段：xmin（插入该版本的事务 ID）和 xmax（删除/更新该版本的事务 ID）。当一个事务读取数据时，会根据自己的事务快照判断：哪些版本对自己「可见」。

事务 100 插入一行  →  xmin=100, xmax=0   (可见)
事务 101 更新该行  →  旧版本 xmax=101, 新版本 xmin=101 (旧版本对 101 之后不可见)

那个 xmax=101 的旧版本，就是死元组。它不会被立刻物理删除，因为可能还有长事务需要看到它。只有当没有任何事务还需要它时，autovacuum 才会把它回收。

关键点在于：死元组在被回收前，依然占用空间、依然被索引引用。这就是膨胀的来源。

2.2 膨胀（bloat）的代价

膨胀不是「占点磁盘」那么简单，它有连锁反应：

• 顺序扫描变慢：表里混着大量死元组，扫 1 亿行可能要读 3 亿行的量。
• 索引膨胀更严重：每个索引条目都指向某个版本，死元组越多，索引越大，缓存命中率越低。
• 统计信息失真：n_dead_tup 很高时，优化器可能选错执行计划。
• 冻结（freeze）压力：死元组堆积会推高事务 ID 年龄，逼近 autovacuum_freeze_max_age 时触发激进 anti-wraparound vacuum，那一刻的 IO 风暴谁用谁知道。

2.3 VACUUM / VACUUM FULL / pg_repack 三者的区别

这是面试和运维都必考的点，但很多人只背结论，不理解取舍：

VACUUM 只是把死元组占的位置标记为「可复用」，表文件大小不变；VACUUM FULL 会建一张新表把活数据拷过去，彻底压缩，但过程锁表。pg_repack 用「建影子表 + 增量同步 + 原子切换」绕开了长时间锁表，是过去生产环境唯一体面的选择——但它需要你预先装好扩展、单独维护、并且 REPACK 期间仍有瞬时的切换锁。

2.4 Autovacuum 的触发与代价模型

autovacuum 不是「定时任务」，而是基于阈值的条件触发。一张表成为候选，当满足：

死元组数 ≥ autovacuum_vacuum_scale_factor × 表行数 + autovacuum_vacuum_threshold

也就是说，默认 scale_factor=0.2、threshold=50：一张 100 万行的表，要攒够 20 万 + 50 = 200050 个死元组才会触发一次 vacuum。对高写入表来说，这个阈值实在太宽松了。

而 autovacuum 真正「温柔」的秘密在代价模型：它每处理一些页就累计 cost，达到 autovacuum_vacuum_cost_limit（默认从 vacuum_cost_limit=200 继承）就休眠 autovacuum_vacuum_cost_delay（PG12+ 默认 2ms）。这个设计本意是别抢业务 IO，但副作用是：大表 vacuum 可能要跑很久，死元组清理永远滞后。

理解了这套机制，你就能看懂 PostgreSQL 19 的三大改动为什么是「对症下药」。

三、架构分析：PostgreSQL 19 到底改了什么

3.1 REPACK ... CONCURRENTLY：内置零停机重建

PostgreSQL 19 把过去只能靠 pg_repack 扩展做的事，做成了内建的 REPACK 命令，并且原生支持 CONCURRENTLY：

-- 重建整张表（含其所有索引），业务照常读写
REPACK TABLE CONCURRENTLY public.orders;

-- 只重建某个膨胀严重的索引，更轻量
REPACK INDEX CONCURRENTLY public.orders_pkey;

它的底层思路与 pg_repack 一脉相承：创建影子表/影子索引 → 持有初始快照拷贝数据 → 通过触发器或逻辑解码增量追平增量写 → 在最后极短的瞬间做原子切换。区别在于，现在是内核原生能力，不再依赖外部扩展，也不再需要你为「扩展版本和 PG 大版本是否匹配」操心。

为什么这是范式级改进？因为「在线瘦身」从一项需要 DBA 专门排期的运维工程，变成了一条随手可发的 SQL。配合 CONCURRENTLY，你甚至可以在业务高峰对膨胀表做局部抢救，而不必苦等凌晨。

注意：虽叫 CONCURRENTLY，切换那一瞬间仍会获取极短暂的 ACCESS EXCLUSIVE 锁来完成替換。它远短于 VACUUM FULL 的全程锁表，但「完全零锁」是个误区——真正的价值是锁的时长从「分钟级」降到「毫秒级」。

3.2 Parallel Autovacuum：并行只在「索引清理」阶段

PostgreSQL 13 起，手工 VACUUM (PARALLEL n) 就能并行，但 autovacuum 一直只能单线程。PostgreSQL 19 终于把这个能力带到了后台自动清理：

• 新增集群级 GUC：autovacuum_max_parallel_workers，限制整个集群并行 autovacuum worker 的总数，worker 来自既有的 max_parallel_workers 资源池。
• 新增表级存储参数：autovacuum_parallel_workers，针对单表单独配置并行度。

但这里的「并行」有个绝大多数文章没讲清的关键点：并行化发生的阶段，只有索引清理（index cleanup）。

一张表的 VACUUM 分三段：

1. Heap Scan：扫描堆、构建死元组列表 —— 仍然单线程。
2. Index Cleanup：清理各个索引里指向死元组的条目 —— 这一段可以并行。
3. Heap Truncation：末尾空闲页截断归还 OS —— 仍然单线程。

所以，真正的变化是：当一张表有 N 个索引时，可以把这 N 个索引分给 N-1 个 worker 加上 leader 同时清理。

-- 集群级：允许最多 8 个并行 autovacuum worker
ALTER SYSTEM SET autovacuum_max_parallel_workers = 8;
SELECT pg_reload_conf();

-- 表级：对一张有十几个索引的宽表单独提高并行度
ALTER TABLE public.user_events
  SET (autovacuum_parallel_workers = 4);

这个结论很重要：如果你的表只有一个主键 B-tree，没有其他索引，那么 Parallel Autovacuum 对你毫无收益——leader 自己就把活干完了，没有多余的索引可分配，Heap Scan 也不并行。它真正发力的场景是：索引多、或索引代价高的表，比如 jsonb 上的 GIN 索引、Partial Index、BRIN 等。在宽表场景里，GIN Cleanup 往往是 vacuum 的主要耗时来源，此时「一个 worker 专攻 GIN，leader 顺手清轻量 B-tree」的并行化才产生实打实的收益。

3.3 优先级 Autovacuum 与 pg_stat_autovacuum_scores

过去 autovacuum 按「发现顺序」处理候选表，结果就是：急表（频繁更新、膨胀飞快的核心表）可能一直排在长事务后面干等，而非急表反而占着资源。PostgreSQL 19 引入了优先级机制——谁急谁先来。

配套新增了 pg_stat_autovacuum_scores 视图，让你一眼看清每张表的「紧急分」：

SELECT relname,
       score,
       would_vacuum,
       would_analyze
FROM pg_stat_autovacuum_scores
ORDER BY score DESC
LIMIT 20;

score 综合了死元组比例、事务 ID 年龄、表大小等因素；would_vacuum / would_analyze 直接告诉你这张表当下是否会被纳入下一轮清理。这意味着 DBA 第一次有了可观测、可预期的清理排队视图，而不是盯着 pg_stat_user_tables 凭感觉猜。

四、代码实战：一步步用起来

下面用一套可落地的操作，把三个特性串起来。假设我们有一张订单表 orders 和一张事件表 user_events，都是高写入核心表。

4.1 先给表做一次「体检」：量化膨胀

不要凭感觉，先用量化指标说话。一个无需安装扩展的近似查询，按死元组比例排序：

SELECT
  schemaname,
  relname,
  n_live_tup,
  n_dead_tup,
  round(n_dead_tup::numeric / NULLIF(n_live_tup, 0) * 100, 2) AS dead_ratio_pct,
  last_autovacuum,
  last_vacuum
FROM pg_stat_user_tables
WHERE n_dead_tup > 1000
ORDER BY dead_ratio_pct DESC NULLS LAST
LIMIT 20;

如果某张表 dead_ratio_pct 长期 > 20%，就该动手了。想看真实的空间膨胀率（死元组占了多少字节），装个官方扩展更直观：

CREATE EXTENSION IF NOT EXISTS pgstattuple;
SELECT * FROM pgstattuple('public.orders');
-- 关注 dead_tuple_percent / free_space / table_len

4.2 零停机重建索引

发现 orders_pkey 膨胀严重（比如 pgstatindex 显示有效数据占比很低），直接在线重建：

-- 只重建索引，最快、影响最小
REPACK INDEX CONCURRENTLY public.orders_pkey;

-- 如果整表都膨胀，重建整表（含全部索引）
REPACK TABLE CONCURRENTLY public.orders;

对比旧方案：过去要做同样的事得先 CREATE EXTENSION pg_repack，再 pg_repack -t public.orders dbname，还得担心扩展与 PG 版本兼容。现在一条 SQL 完事，且 CONCURRENTLY 保证业务不中断。

4.3 开启并行 Autovacuum（集群级 + 表级）

先给集群放开并行上限，再对宽表单独提并行度：

-- 1) 集群级：允许并行 autovacuum worker 总数
ALTER SYSTEM SET autovacuum_max_parallel_workers = 8;
SELECT pg_reload_conf();

-- 2) 表级：user_events 有十几个索引，给 4 个并行 worker
ALTER TABLE public.user_events
  SET (autovacuum_parallel_workers = 4);

-- 3) 验证表级参数已生效
SELECT relname,
       reloptions
FROM pg_class
WHERE relname = 'user_events';
-- 应看到 {autovacuum_parallel_workers=4}

注意：autovacuum_max_parallel_workers 的 worker 来自 max_parallel_workers 池子，默认是关闭并行（值为 0）的，这是合理的保守默认值——你需要显式打开，且要确保 max_parallel_workers 有足够余量，否则会和查询的并行资源互相挤占。

4.4 用优先级视图识别「急表」

-- 找出最该被优先清理的表
SELECT
  c.relname,
  s.score,
  s.would_vacuum,
  s.would_analyze,
  t.n_dead_tup,
  t.last_autovacuum
FROM pg_stat_autovacuum_scores s
JOIN pg_class c ON c.oid = s.relid
JOIN pg_stat_user_tables t ON t.relname = c.relname
WHERE s.would_vacuum
ORDER BY s.score DESC
LIMIT 10;

如果一张核心表 would_vacuum = true 但 last_autovacuum 很久远、死元组仍在涨，说明它虽然进了优先级队列，但资源被别的大表吃掉了——这时就该给这张表单独提并行度，或临时手动 VACUUM (PARALLEL 4) public.核心表; 救急。

4.5 一份可直接落地的 postgresql.conf 片段

把上面的理念落成配置（生产环境请按机器规格和负载微调）：

# ---- PostgreSQL 19 运维范式相关 ----
autovacuum = on
autovacuum_max_workers = 6              # 同时跑的 autovacuum 进程数
autovacuum_max_parallel_workers = 8     # 并行 autovacuum worker 上限

# 代价模型：默认 200 太保守，大表永远清不完
autovacuum_vacuum_cost_limit = 2000     # 提高单轮 IO 预算
autovacuum_vacuum_cost_delay = 2ms      # PG12+ 默认值，保持即可

# 可观测性：慢 vacuum 记日志，便于发现异常表
log_autovacuum_min_duration = 1s

# 高写入核心表单独调阈值（也可在表级用 ALTER TABLE ... SET）
# autovacuum_vacuum_scale_factor = 0.1
# autovacuum_vacuum_threshold = 5000

改完后 SELECT pg_reload_conf(); 让大多数参数热加载（autovacuum_max_workers 等少数参数需重启）。

五、性能优化：别被「并行」骗了

特性再好，用错地方就是浪费。这一节讲清什么时候该上、什么时候别碰。

5.1 Parallel Autovacuum 真正生效的前提

记住唯一判据：表要有多个、或高代价的索引。

• ✅ 适合：宽表（十几个 B-tree）、jsonb 上的 GIN、Partial Index、BRIN。GIN Cleanup 往往是 vacuum 耗时大头，并行化收益最大。
• ❌ 无效：只有单列主键的窄表。Heap Scan 不并行、索引只有一个，worker 无活可分，纯属配置摆设。
• ⚠️ 警惕资源挤占：并行 worker 来自 max_parallel_workers 池。如果查询本身也大量用并行，两者会抢资源，反而让业务查询变慢。务必给 autovacuum_max_parallel_workers 设一个低于 max_parallel_workers 的上限，留余量给查询。

5.2 代价模型调优：让清理「跟得上」

默认 autovacuum_vacuum_cost_limit = 200（从 vacuum_cost_limit 继承）是 PG 早期为机械盘设计的保守值。现代 SSD 上这个值太小，导致大表 vacuum 跑得像蜗牛。

• 把 cost_limit 提到 10002000，等价于允许 vacuum 每轮多干 510 倍 IO。
• cost_delay 在 PG12+ 默认 2ms，已经很友好，通常不用动。
• 不要全局无脑激进：cost_limit 太高会让 vacuum 抢占业务 IO。折中做法是全局保持温和，对少数超高写入表用表级 autovacuum_vacuum_cost_limit 单独放开。

表级单独放开代价的写法：

ALTER TABLE public.orders
  SET (autovacuum_vacuum_cost_limit = 2000,
       autovacuum_vacuum_scale_factor = 0.05,
       autovacuum_vacuum_threshold = 5000);

这里把 scale_factor 从 0.2 降到 0.05，意味着死元组刚到 5% 就开始清，从源头压制膨胀。

5.3 监控与告警：把「被动救火」变「主动巡检」

三个视图必须纳入监控看板：

-- 1) 膨胀Top榜（见 4.1）
-- 2) 优先级清理队列（见 4.4）
-- 3) 事务 ID 年龄，防止 wraparound 风暴
SELECT datname,
       age(datfrozenxid) AS xid_age
FROM pg_database
ORDER BY xid_age DESC;
-- 超过 autovacuum_freeze_max_age(默认2亿) 的 80% 就要告警

建议告警规则：

• 任意表 dead_ratio_pct > 30% 持续 10 分钟 → 触发 REPACK 评估。
• 任意库 xid_age > 1.6 亿 → 立即排查长事务/长连接。
• log_autovacuum_min_duration 记录到超过 60s 的 vacuum → 该表需要专项调优。

5.4 三个常见误区

1. 「开了并行 autovacuum，所有表都变快」——错。只有多索引/高代价索引表受益，窄表单线程毫无变化。
2. 「REPACK CONCURRENTLY 完全无锁」——错。切换瞬间仍有极短 ACCESS EXCLUSIVE，只是从分钟级降到毫秒级，别在它上面叠加别的 DDL。
3. 「autovacuum 越频繁越好」——错。频繁 vacuum 本身也是写 IO 和 WAL。代价模型的意义就是平衡：跟得上业务即可，不是越勤越好。真正该做的是降低触发阈值 + 提高单轮 IO 预算，而不是无限拉高频率。

六、总结与展望：从「手动挡」到「自动驾驶」

PostgreSQL 19 这三个改动单独看都是「小步」，合起来却是一个清晰的信号：PostgreSQL 正在把运维知识从「人脑」迁移到「内核」。

• REPACK ... CONCURRENTLY 让「在线瘦身」从 DBA 工程降级为一条 SQL；
• Parallel Autovacuum 让清理第一次能利用多核，且精准作用于索引瓶颈；
• pg_stat_autovacuum_scores 让清理排队第一次可观测、可预期。

这背后是数据库自治（self-driving database）的大趋势。当云厂商已经在做 AI 调参（用向量/强化学习自动搜最优 GUC），PostgreSQL 19 在内核层补齐了「原生零停机运维」的能力地基。对中小团队尤其友好：你不再需要专职 DBA 半夜盯着膨胀，也不必先搞定 pg_repack 扩展的版本兼容。

升级建议：

• 已经在用 PG 16/17/18 的团队，可以把 19 纳入明年大版本规划，重点验证 REPACK 与现有 pg_repack 脚本的迁移（19 内建后，旧扩展可逐步退役）。
• 升级前用 pg_stat_autovacuum_scores 的思路预先梳理「急表清单」，配合表级并行参数做灰度。
• 把本文 5.3 的监控视图接进看板，让「膨胀」和「事务年龄」成为日常可观测指标，而不是事故后的复盘原因。

PostgreSQL 的强项从来不是某个花哨特性，而是「把难的事做对、做稳」。19 这版，把「运维」这件最难的事，悄悄往前推进了一大步。对还在半夜爬起来 REPACK 的 DBA 来说，这大概就是最好的年度礼物。

参考来源：PostgreSQL 19 预发特性综述、IvorySQL 关于 PG 19 Parallel Autovacuum 的实测分析、PostgreSQL 官方 autovacuum 文档与社区邮件列表讨论。