KES 数据库运维：资源回收与膨胀防治全攻略

二、垃圾回收原理：为什么表会膨胀？

KES 基于 MVCC（多版本并发控制）机制，更新和删除操作不会立即物理删除旧版本数据，而是保留为死亡元组（dead tuple）。这些死亡元组需要由 VACUUM 机制定期回收，否则就会造成表膨胀。

导致膨胀的八大根因

1. 未开启 autovacuum：最直接的原因。没有自动回收机制，死亡元组只会越堆越多。
2. autovacuum 触发阈值过高：默认触发条件为 threshold = autovacuum_vacuum_threshold + autovacuum_vacuum_scale_factor × reltuples。默认 scale_factor = 0.2，意味着死亡元组达到表总行数的 20% 才触发回收，膨胀已成事实。
3. autovacuum worker 进程不足：默认 autovacuum_max_workers = 3，当需要清理的表超过 3 张时，其余表只能排队等待。
4. 长 SQL 或长事务持有 xmin：这是生产环境最隐蔽、危害最大的原因，详见下一节。
5. 开启了 autovacuum_vacuum_cost_delay：基于成本的限速机制会显著拖慢垃圾回收速度，IO 正常的系统不建议开启。
6. autovacuum_naptime 设置过长：launcher 进程唤醒间隔过长，垃圾堆积无人处理。
7. 大批量删除或更新：单事务删除/更新大量数据，事务提交前这些垃圾版本完全无法回收。
8. 大量非 HOT 更新导致索引膨胀：B-Tree 索引整页无引用才能被回收，非 HOT 更新会快速撑大索引体积。

并发批量更新的膨胀实测

以下测试将 100 万行数据分 10 个进程持续并发更新，观察膨胀过程：

初始状态 表大小：73 MB 索引大小：21 MB 10 进程并发持续更新后 表大小：335 MB 索引大小：48 MB

autovacuum 日志中可以观察到大量不可回收的死亡元组：

tuples: 0 removed, 2049809 remain, 999991 are dead but not yet removable
tuples: 501373 removed, 2176172 remain, 999991 are dead but not yet removable

根本原因：autovacuum worker 是表级粒度，同一张表同一时间只有一个 worker 在工作。并发更新事务持有的排他锁会阻断回收过程，产生 'not yet removable' 的死亡元组，最终迫使数据库扩展新数据块。

改进方法：将大批量更新切分为多个小事务，缩短单事务持有时间，减少 not yet removable 的发生概率。

三、长事务：阻止 VACUUM 的隐形拦路虎

三类典型的长事务场景

KES 中，以下三种情况都会持续持有 backend_xmin，阻止其后产生的垃圾版本被回收：

场景一：打开游标后不关闭

BEGIN;
DECLARE c1 CURSOR FOR SELECT 1 FROM sys_class;
-- 游标不关闭，backend_xmin 持续存在
-- 此期间产生的所有垃圾版本均无法回收
CLOSE c1; -- 关闭后 xmin 才释放

场景二：长时间运行的查询

BEGIN;
SELECT pg_sleep(1000);
-- 执行期间 backend_xmin 持续持有
-- 语句取消或结束后 xmin 才释放

场景三：REPEATABLE READ / SERIALIZABLE 隔离级别事务

BEGIN WORK ISOLATION LEVEL REPEATABLE READ;
SELECT 1;
-- backend_xmin 持续到 COMMIT / ROLLBACK
END;

长事务阻止 VACUUM FREEZE 的实测验证

-- 第一个长事务（xid: 1668525）未结束时 VACUUM (FREEZE, VERBOSE) t2;
-- 结果：0 frozen pages，年龄无法下降
-- "oldest xmin: 1668525"
-- 结束第一个事务后，第二个长事务（xid: 1788896）仍在 VACUUM (FREEZE, VERBOSE) t2;
-- 结果：年龄有所下降，但仍无法归零
-- 两个长事务全部结束后 VACUUM (FREEZE, VERBOSE) t2;
-- 结果：age = 0，完全冻结成功 ✅

关键结论：不仅是目标表的长事务会阻止其 VACUUM FREEZE，其他表的长事务同样会阻止所有表的冻结推进。这是生产环境中表年龄居高不下的最常见原因。

监控长事务的实用 SQL

-- 监控持有 xmin 的活跃会话（超过 30 分钟）
SELECT datname, usename, query, xact_start, now() - xact_start AS xact_duration, state
FROM sys_stat_activity
WHERE state <> 'idle'
  AND (backend_xid IS NOT NULL OR backend_xmin IS NOT NULL)
  AND now() - xact_start > INTERVAL '30 min'
ORDER BY xact_start;

-- 监控两阶段提交中未提交的预备事务
SELECT gid, prepared, owner, database, transaction AS xmin
FROM sys_prepared_xacts
ORDER BY age(transaction) DESC;

-- 监控复制槽是否因备库长事务阻塞 xmin 推进
SELECT * FROM sys_replication_slots ORDER BY age(xmin) DESC;

四、autovacuum 精细化调优：表级参数设置

全局 autovacuum 参数是一刀切的，对于高频更新的核心表，表级参数设置是更精准的解法。

表级参数配置示例

-- 开启表级 autovacuum 并设置精细化阈值
ALTER TABLE t2 SET (autovacuum_enabled = true);
ALTER TABLE t2 SET (autovacuum_vacuum_threshold = 1);
ALTER TABLE t2 SET (autovacuum_vacuum_scale_factor = 0);
-- 关键：必须同时设置为 0
-- 同理设置 analyze 相关参数
ALTER TABLE t2 SET (autovacuum_analyze_threshold = 1);
ALTER TABLE t2 SET (autovacuum_analyze_scale_factor = 0);

⚠️ 重要提示：如果只设置 autovacuum_vacuum_threshold = 1 而不设置 autovacuum_vacuum_scale_factor = 0，则触发条件仍会叠加全局的 scale_factor = 0.2，导致阈值远高于预期。两个参数必须配合使用。

触发阈值计算逻辑

全局调优建议清单

针对不同场景，以下是经过实测验证的调优建议：

1. 必须开启 autovacuum — 这是底线，任何情况下不应关闭
2. 提升存储 IO 能力 — 高性能 SSD 是 VACUUM 高效运行的物理基础
3. 调小 scale_factor — 对大表设置 autovacuum_vacuum_scale_factor = 0.001，避免等到 20% 才触发
4. 增加 worker 进程数 — 表多且大的场景，autovacuum_max_workers 可调整至与 CPU 核数一致，同时将 autovacuum_work_mem 调整为 2GB
5. 避免长事务 — 包括长 SQL、未关闭游标、不必要的 REPEATABLE READ 隔离级别、sys_dump 逻辑备份期间的隐式长事务
6. 关闭 cost_delay 限速 — IO 正常的系统无需开启 autovacuum_vacuum_cost_delay
7. 切分大批量操作 — 将大事务拆分为多个小事务，降低 not yet removable 概率
8. 膨胀后的修复手段 — 常规 VACUUM 无法收缩已膨胀的表，需使用 VACUUM FULL 或 CLUSTER（需持排他锁，建议业务低峰期执行），或使用 sys_squeeze 插件（依赖逻辑解码，需设置 wal_level = logical）实现在线收缩

五、总结：构建 KES 资源回收的完整防线

KES 的资源回收体系是一个多层联动的精密机制，任何一个环节的疏漏都可能引发连锁膨胀。

索引膨胀 → REINDEX CONCURRENTLY → 不停机重建
表膨胀 → autovacuum 精细调优 → 及时回收死亡元组
长事务 → 主动监控 + 及时终止 → 解除 xmin 阻断
年龄积累 → VACUUM FREEZE → 防止事务 ID 回卷

作为 DBA，主动监控优于被动响应。建立长事务告警、定期检查膨胀率、合理配置 autovacuum 参数，是保障 KES 数据库长期健康运行的核心运维实践。在生产环境中，与业务团队充分沟通长事务的潜在风险，从应用设计层面规避问题的根源，才是最根本的解决之道。