PostgreSQL 9.6版本VACUUM操作对用户及DML命令的影响咨询

作为长期使用PostgreSQL的老玩家，结合9.6版本的特性，给你拆解清楚不同VACUUM操作对业务的影响——你提到的「Execute vacuum online」应该就是指常规的VACUUM（不带FULL参数），PG里没有专门叫"vacuum online"的命令，不过常规VACUUM本身就是低干扰、不阻塞业务的操作，下面分两类场景说明：

一、常规VACUUM（手动执行VACUUM/VACUUM ANALYZE，或自动触发的autovacuum） #

这是日常维护的主力操作，对终端用户和业务几乎无破坏性影响：

• 对DML/查询的阻塞情况：它只会加SHARE UPDATE EXCLUSIVE锁，这种锁不会阻塞常规的SELECT、INSERT、UPDATE、DELETE操作，唯一的限制是会阻止少数高风险DDL（比如ALTER TABLE重命名表、DROP TABLE这类），但这类操作日常业务里本来就不会频繁执行。
• 性能影响：执行时会占用一些CPU和IO资源来扫描表、清理死元组，可能带来轻微的性能波动，但9.6版本对VACUUM的资源控制做了优化，只要服务器资源不是特别吃紧，终端用户基本感知不到。
• 自动autovacuum更省心：PG会根据表的更新频率、死元组数量自动触发，还能通过配置参数调整执行时机（避开业务高峰），比手动执行更稳妥，不会突然占用大量资源。

二、VACUUM FULL（手动执行VACUUM FULL） #

这个操作要格外谨慎，它的行为和常规VACUUM完全不同：

• 锁表风险：执行时会对目标表加ACCESS EXCLUSIVE锁，这意味着在操作完成前，所有对该表的查询、增删改操作都会被阻塞，终端用户的业务会直接卡住，直到VACUUM FULL结束。
• 适用场景：它会彻底回收死元组占用的磁盘空间，把表压缩成连续的磁盘块，但代价就是阻塞业务，所以只建议在非业务高峰、表膨胀特别严重且常规VACUUM无法回收空间时使用。

三、给新手的实用建议 #

• 日常维护完全依赖自动autovacuum即可，不用手动频繁执行常规VACUUM；
• 除非万不得已，绝对不要在业务高峰时段执行VACUUM FULL；
• 如果需要手动执行常规VACUUM，尽量选在业务低峰期，减少资源竞争带来的轻微性能波动。

内容的提问来源于stack exchange，提问作者user2671057