在数据库长期运行过程中,表膨胀与索引膨胀是 KingbaseES（KES）DBA 最常面对的"隐形杀手"。它们悄无声息地蚕食磁盘空间、拖慢查询性能,严重时甚至威胁系统稳定性。本文从索引重建、垃圾回收原理、长事务阻断、autovacuum 精细化调优四个维度,系统梳理 KES 资源回收的核心机制与实战方法。
一、REINDEX CONCURRENTLY：不停机重建膨胀索引
随着业务 DML 语句持续增长,索引会像表一样发生膨胀。膨胀的索引不仅浪费磁盘空间,还会显著降低查询性能——新构建的索引往往比反复更新的旧索引提供更好的访问效率。
为什么不能直接用 REINDEX？
普通REINDEX命令需要ACCESS EXCLUSIVE 锁,这是最高级别的锁,会阻塞一切业务语句,生产环境中几乎不可接受。
解决方案是使用REINDEX ... CONCURRENTLY,其锁级别降为SHARE UPDATE EXCLUSIVE,不阻塞 DML 操作,实现业务无感知的索引重建。
REINDEX CONCURRENTLY 的六个执行阶段
| 阶段 | 操作内容 | 关键说明 |
|---|---|---|
| ① 创建新索引 | 生成临时索引,命名以idx_ccnew开头 | 此时新索引为空,尚未包含数据 |
| ② 构建新索引 | 全表扫描,填充新索引内容 | 期间新写入数据同步进入新索引 |
| ③ 验证新索引 | 将构建阶段新插入的数据补充进索引 | 类似CREATE INDEX CONCURRENTLY的逻辑 |
| ④ 交换索引 | 新旧索引互换,旧索引标记为invalid | 业务流量切换至新索引 |
| ⑤ 标记旧索引为 dead | indislive、indisready、indisvalid均置为 false | 旧索引彻底退出服务 |
| ⑥ 删除旧索引 | 物理清除旧索引占用的磁盘空间 | 完成整个重建流程 |
识别异常残留的无效索引
如果REINDEX CONCURRENTLY中途失败,可能留下名称含_ccnew的无效索引,需及时清理：
SELECTc.relnameASindex_name,sys_size_pretty(sys_relation_size(c.oid))FROMsys_index iJOINsys_class cONi.indexrelid=c.oidWHEREc.relnameLIKE'%_ccnew'-- 重建过程产生的临时索引ANDNOTindisvalid-- 处于 INVALID 状态LIMIT10;二、垃圾回收原理：为什么表会膨胀？
KES 基于 MVCC（多版本并发控制）机制,更新和删除操作不会立即物理删除旧版本数据,而是保留为"死亡元组"（dead tuple）。这些死亡元组需要由VACUUM机制定期回收,否则就会造成表膨胀。
导致膨胀的八大根因
① 未开启 autovacuum
最直接的原因。没有自动回收机制,死亡元组只会越堆越多。
② autovacuum 触发阈值过高
默认触发条件为：
threshold=autovacuum_vacuum_threshold+autovacuum_vacuum_scale_factor×reltuples\text{threshold} = \text{autovacuum\_vacuum\_threshold} + \text{autovacuum\_vacuum\_scale\_factor} \times \text{reltuples}threshold=autovacuum_vacuum_threshold+autovacuum_vacuum_scale_factor×reltuples
默认scale_factor = 0.2,意味着死亡元组达到表总行数的20%才触发回收,膨胀已成事实。
③ autovacuum worker 进程不足
默认autovacuum_max_workers = 3,当需要清理的表超过 3 张时,其余表只能排队等待。
④ 长 SQL 或长事务持有 xmin
这是生产环境最隐蔽、危害最大的原因,详见下一节。
⑤ 开启了 autovacuum_vacuum_cost_delay
基于成本的限速机制会显著拖慢垃圾回收速度,IO 正常的系统不建议开启。
⑥ autovacuum_naptime 设置过长
launcher 进程唤醒间隔过长,垃圾堆积无人处理。
⑦ 大批量删除或更新
单事务删除 / 更新大量数据,事务提交前这些垃圾版本完全无法回收。
⑧ 大量非 HOT 更新导致索引膨胀
B-Tree 索引整页无引用才能被回收,非 HOT 更新会快速撑大索引体积。
并发批量更新的膨胀实测
以下测试将 100 万行数据分 10 个进程持续并发更新,观察膨胀过程：
-- 初始状态 表大小：73 MB 索引大小：21 MB -- 10 进程并发持续更新后 表大小：335 MB 索引大小：48 MBautovacuum 日志中可以观察到大量不可回收的死亡元组：
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;DECLAREc1CURSORFORSELECT1FROMsys_class;-- 游标不关闭,backend_xmin 持续存在-- 此期间产生的所有垃圾版本均无法回收CLOSEc1;-- 关闭后 xmin 才释放场景二：长时间运行的查询
BEGIN;SELECTpg_sleep(1000);-- 执行期间 backend_xmin 持续持有-- 语句取消或结束后 xmin 才释放场景三：REPEATABLE READ / SERIALIZABLE 隔离级别事务
BEGINWORKISOLATIONLEVELREPEATABLEREAD;SELECT1;-- backend_xmin 持续到 COMMIT / ROLLBACKEND;长事务阻止 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 分钟）SELECTdatname,usename,query,xact_start,now()-xact_startASxact_duration,stateFROMsys_stat_activityWHEREstate<>'idle'AND(backend_xidISNOTNULLORbackend_xminISNOTNULL)ANDnow()-xact_start>INTERVAL'30 min'ORDERBYxact_start;-- 监控两阶段提交中未提交的预备事务SELECTgid,prepared,owner,database,transactionASxminFROMsys_prepared_xactsORDERBYage(transaction)DESC;-- 监控复制槽是否因备库长事务阻塞 xmin 推进SELECT*FROMsys_replication_slotsORDERBYage(xmin)DESC;四、autovacuum 精细化调优：表级参数设置
全局 autovacuum 参数是"一刀切"的,对于高频更新的核心表,表级参数设置是更精准的解法。
表级参数配置示例
-- 开启表级 autovacuum 并设置精细化阈值ALTERTABLEt2SET(autovacuum_enabled=true);ALTERTABLEt2SET(autovacuum_vacuum_threshold=1);ALTERTABLEt2SET(autovacuum_vacuum_scale_factor=0);-- 关键：必须同时设置为 0-- 同理设置 analyze 相关参数ALTERTABLEt2SET(autovacuum_analyze_threshold=1);ALTERTABLEt2SET(autovacuum_analyze_scale_factor=0);⚠️重要提示：如果只设置
autovacuum_vacuum_threshold = 1而不设置autovacuum_vacuum_scale_factor = 0,则触发条件仍会叠加全局的scale_factor = 0.2,导致阈值远高于预期。两个参数必须配合使用。
触发阈值计算逻辑
| 参数组合 | 触发条件（10行表） | 实际效果 |
|---|---|---|
仅设置threshold=1（全局 scale=0.2） | 1+0.2×10=31 + 0.2 \times 10 = 31+0.2×10=3条死亡元组 | 更新 3 条才触发 |
threshold=1+scale_factor=0 | 1+0×10=11 + 0 \times 10 = 11+0×10=1条死亡元组 | 更新 2 条即触发 |
threshold=大数+scale_factor=1 | 永远不满足 | 禁用 autoanalyze |
全局调优建议清单
针对不同场景,以下是经过实测验证的调优建议：
- 必须开启 autovacuum— 这是底线,任何情况下不应关闭
- 提升存储 IO 能力— 高性能 SSD 是 VACUUM 高效运行的物理基础
- 调小 scale_factor— 对大表设置
autovacuum_vacuum_scale_factor = 0.001,避免等到 20% 才触发 - 增加 worker 进程数— 表多且大的场景,
autovacuum_max_workers可调整至与 CPU 核数一致,同时将autovacuum_work_mem调整为 2GB - 避免长事务— 包括长 SQL、未关闭游标、不必要的 REPEATABLE READ 隔离级别、
sys_dump逻辑备份期间的隐式长事务 - 关闭 cost_delay 限速— IO 正常的系统无需开启
autovacuum_vacuum_cost_delay - 切分大批量操作— 将大事务拆分为多个小事务,降低 not yet removable 概率
- 膨胀后的修复手段— 常规 VACUUM 无法收缩已膨胀的表,需使用
VACUUM FULL或CLUSTER（需持排他锁,建议业务低峰期执行）,或使用sys_squeeze 插件（依赖逻辑解码,需设置wal_level = logical）实现在线收缩
五、总结：构建 KES 资源回收的完整防线
KES 的资源回收体系是一个多层联动的精密机制,任何一个环节的疏漏都可能引发连锁膨胀。
索引膨胀 → REINDEX CONCURRENTLY → 不停机重建 表膨胀 → autovacuum 精细调优 → 及时回收死亡元组 长事务 → 主动监控 + 及时终止 → 解除 xmin 阻断 年龄积累 → VACUUM FREEZE → 防止事务 ID 回卷作为 DBA,主动监控优于被动响应。建立长事务告警、定期检查膨胀率、合理配置 autovacuum 参数,是保障 KES 数据库长期健康运行的核心运维实践。在生产环境中,与业务团队充分沟通长事务的潜在风险,从应用设计层面规避问题的根源,才是最根本的解决之道。
