网站右侧返回顶部,贵州省住房和城乡建设厅官网站,长沙做网站kaodezhu,windows2008网站PostgreSQL 的 VACUUM 与 VACUUM FULL 详解
一、基本概念对比
特性VACUUMVACUUM FULL定义常规维护操作#xff0c;清理死元组激进重组操作#xff0c;完全重写表数据锁级别不阻塞读写(共享锁)排他锁(阻塞所有操作)空间回收只标记空间为可用#xff0c;不返还OS空间返还操作…PostgreSQL 的 VACUUM 与 VACUUM FULL 详解
一、基本概念对比
特性VACUUMVACUUM 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