PostgreSQL 的 VACUUM 与 VACUUM FULL 详解
PostgreSQL 的 VACUUM 与 VACUUM FULL 详解
一、基本概念对比
| 特性 | VACUUM | VACUUM FULL |
|---|---|---|
| 定义 | 常规维护操作，清理死元组 | 激进重组操作，完全重写表数据 |
| 锁级别 | 不阻塞读写(共享锁) | 排他锁(阻塞所有操作) |
| 空间回收 | 只标记空间为可用，不返还OS | 空间返还操作系统 |
| 索引处理 | 不重建索引 | 完全重建所有索引 |
| 执行速度 | 快(增量式) | 慢(全量重写) |
| 对系统影响 | 低 | 高 |
二、工作机制详解
1. VACUUM 工作原理
- 死元组清理：标记被删除或更新旧版本的数据为"可重用"
- 事务ID处理：防止事务ID回卷(冻结旧事务ID)
- 更新统计信息：为查询优化器提供最新数据分布信息
- 不减少物理文件大小：只是内部空间重用
2. VACUUM FULL 工作原理
- 创建表的全新副本
- 只将有效数据写入新存储
- 删除原始表文件
- 将新文件重命名为原表名
- 完全重建所有索引（因为元组物理位置改变）
三、使用场景对比
适合使用 VACUUM 的场景
- 常规数据库维护(建议配置autovacuum)
- 高并发OLTP系统
- 频繁更新的表(每天或每小时)
- 只需要空间重用，不需OS空间回收
适合使用 VACUUM FULL 的场景
- 表膨胀严重(>30%空间浪费)
- 准备进行大版本升级前
- 长期未维护的历史表
- 需要彻底重组表物理结构时
四、性能影响分析
VACUUM 影响
-- 典型资源占用
CPU: 5-15%
IO: 中等(取决于表大小)
锁: 不阻塞查询，可能与DDL冲突
持续时间: 几分钟到几小时(大表)
VACUUM FULL 影响
-- 典型资源占用
CPU: 30-70%
IO: 非常高(读写全表数据)
锁: 完全阻塞表访问
持续时间: 几小时到几天(特大表)
五、实际操作示例
基本语法
-- 普通VACUUM
VACUUM [VERBOSE] [ANALYZE] [table_name];
-- 示例
VACUUM VERBOSE ANALYZE orders;-- VACUUM FULL
VACUUM FULL [VERBOSE] [table_name];
-- 示例
VACUUM FULL VERBOSE large_table;
监控命令
-- 查看表膨胀情况
SELECTschemaname || '.' || relname AS table_name,pg_size_pretty(pg_total_relation_size(relid)) AS total_size,pg_size_pretty(pg_relation_size(relid)) AS data_size,n_live_tup AS live_tuples,n_dead_tup AS dead_tuples,round((n_dead_tup::numeric / (n_live_tup + n_dead_tup) * 100), 2) AS dead_tuple_percent,last_vacuum,last_autovacuum
FROM pg_stat_user_tables
WHERE n_live_tup > 0
ORDER BY dead_tuple_percent DESC;
六、最佳实践建议
-
常规维护策略：
- 启用并合理配置autovacuum
- 对大表设置更频繁的vacuum阈值
ALTER TABLE large_table SET (autovacuum_vacuum_scale_factor = 0.01,autovacuum_vacuum_threshold = 1000 ); -
VACUUM FULL 替代方案：
- 使用pg_repack扩展(在线重组，不阻塞读写)
-- 安装后使用 pg_repack -d dbname -t table_name- 手动创建新表交换(需要更多步骤)
-
特殊场景处理：
- 对于只读表，可以禁用autovacuum
ALTER TABLE historical_data SET (autovacuum_enabled = false );- 紧急空间回收时考虑在维护窗口使用VACUUM FULL