PostgreSQL 中 VACUUM FULL 对索引的影响

是的，VACUUM FULL 会重建表上的所有索引。这是它与普通 VACUUM 命令的一个重要区别。

一、VACUUM FULL 的工作原理

表重建过程：
- 创建表的全新副本
- 只将有效数据写入新存储
- 删除原始表文件
- 将新文件重命名为原表名
索引处理：
- 在表数据完全重写后
- 所有索引会被完全重建
- 索引统计信息也会更新

二、与普通 VACUUM 的对比

特性	VACUUM	VACUUM FULL
是否锁表	不锁表(并发允许)	排他锁(阻塞操作)
空间回收	不返还给操作系统	空间返还操作系统
索引处理	不重建索引	完全重建所有索引
执行速度	快	慢(尤其大表)
对系统影响	低	高

三、索引重建的影响

积极影响：
- 消除索引膨胀
- 提高索引扫描效率
- 更新索引统计信息
- 优化索引结构(减少碎片)
负面影响：
- 重建期间消耗大量CPU/IO资源
- 对大表可能导致长时间不可用
- 需要额外的临时空间(约原表大小)

四、使用建议

适用场景：

sql 复制代码

-- 表有大量更新/删除操作后
-- 索引明显膨胀(用pg_stat_all_indexes查看)
-- 准备进行重要性能敏感操作前

替代方案：

sql 复制代码

-- 常规维护使用普通VACUUM
VACUUM ANALYZE table_name;

-- 使用CREATE TABLE...AS重建(更灵活)
BEGIN;
CREATE TABLE new_table AS SELECT * FROM old_table;
DROP TABLE old_table;
ALTER TABLE new_table RENAME TO old_table;
-- 重建约束和索引...
COMMIT;

监控方法：

sql 复制代码

-- 检查索引膨胀情况
SELECT 
  schemaname || '.' || relname AS table,
  indexrelname AS index,
  pg_size_pretty(pg_relation_size(indexrelid)) AS index_size,
  idx_scan AS index_scans
FROM pg_stat_user_indexes
ORDER BY pg_relation_size(indexrelid) DESC;

五、注意事项

生产环境慎用：
- 在低峰期执行
- 考虑使用pg_repack扩展(在线重组)

空间需求：

sql 复制代码

-- 确保有足够空间(约原表+索引大小的2倍)
SELECT pg_size_pretty(pg_total_relation_size('table_name'));

后续操作：

sql 复制代码

-- 重建后更新统计信息
ANALYZE table_name;

-- 检查重建效果
SELECT n_dead_tup FROM pg_stat_user_tables WHERE relname = 'table_name';

VACUUM FULL 是强大的维护工具，但因其重建索引和锁表的特性，应在充分了解影响后谨慎使用。对于关键业务表，建议优先考虑 pg_repack 等在线重组工具。