开工前先把话说清楚：如果你维护过PostgreSQL，并且某天发现数据库磁盘占用怎么都降不下来、查询越来越慢、或者收到“Transaction ID wraparound”这种告警，那多半就是vacuum没干好活。vacuum这个命令，名字叫“清理”，实际做的东西涉及事务管理、存储引擎、并发控制一堆底层机制。这可能是PostgreSQL里最容易被忽视、但又最不能乱碰的命令之一。
这篇东西不谈教科书概念，直接从为什么要vacuum、vacuum本质做了什么、具体命令怎么用、自动化怎么配、遇到问题怎么排查五个维度来聊。无论你是刚接触PostgreSQL没多久，还是已经踩过坑想系统搞明白，希望看完全文能自己动手排查一轮。
1. 为什么vacuum不是可选项
1.1 MVCC机制带来的“历史包袱”
要理解vacuum，首先得理解PostgreSQL的多版本并发控制（MVCC）机制。简单说，数据库里同一行数据可能同时存在多个版本，不同事务看到不同版本，这保证了读不阻塞写、写不阻塞读。这套机制本身很优雅，但代价是——被更新或删除的老数据版本不会立刻物理删除，而是留在数据文件里，变成一个“死元组”（dead tuple）。
生活化类比：像一栋老楼的楼层索引，每换一次租户，物业不会把旧租户信息撕掉，而是在旁边贴新增条。时间长了，墙上贴了一层又一层，新租户要找自己名字就得翻很久，整栋楼的“内存”也被废纸堆满了。
PostgreSQL里的情况就是这样：一个事务把某行的某个字段从A改成B，旧版本A并不会直接消失，它仍然存在于数据页里，只是对已提交的新事务不可见了。只有等所有可能看到旧版本的事务都结束后，旧版本才真正变为“垃圾”，可以清理。
问题在于，PostgreSQL不会自动检测这些垃圾并且立刻回收。它需要外部的清理动作来“翻垃圾”。这个外部动作，就是vacuum。
1.2 不清理会发生什么
长期不vacuum，后果是逐步累积的，不是一下爆发。大概方向有三个：
- 表膨胀。数据文件里大量空间被死元组占据，磁盘占用越来越大。最严重的情况是没有足够空间写入新数据，数据库实例直接卡死或崩溃。
- 查询变慢。每个查询要扫描的数据页变多。几万条live tuple的表膨胀到几百万个dead tuple时，本来走索引几毫秒的查询变成全表扫描几秒钟。
- 事务ID回卷。这个最隐蔽也最致命。PostgreSQL事务ID是32位整数，最多约42亿个事务。如果vacuum不跑，事务ID会达到极限然后回卷，导致已提交的数据突然变得“不可见”，数据库不得不进入强制下线保护模式。一旦触发强制回卷保护，整个实例只能单用户模式启动处理，生产事故级别。
很多开发者以为“数据不多，不清理也没关系”，其实事务ID回卷和数据量没关系，只看事务产生速度。一个高并发的系统哪怕数据量只有几万条，如果vacuum处理不及，同样可能触雷。这一点做PostgreSQL运维的都应该心有戚戚。
1.3 与MySQL等数据库的差异
用过MySQL的人对“清理”的感知可能不一样。InnoDB的undo log放在独立表空间，purge线程在后台自动清理，不需要用户手动干预。PostgreSQL的旧版本则直接堆在表数据文件里，没有独立的undo区域。因此PostgreSQL的vacuum不是一个可选优化，而是维持系统可用性的必要条件。
这个设计差异直接决定了运维习惯的不同。管理MySQL时很少专门跑清理命令，管理PostgreSQL时，vacuum和执行计划、索引维护一样，属于日常必修科目。
2. vacuum到底在做什么
2.1 常规vacuum的核心动作
vacuum命令在主文档里的描述是“回收存储空间并更新统计信息”，但实际的工作步骤比这句话复杂。
第一步，扫描表中的数据页，识别dead tuple。一个tuple是否可清理，取决于它被哪个事务创建或删除，以及该事务是否已提交且早于当前所有活跃事务的快照。这里的判断逻辑涉及事务ID比较、提交状态检查、clog日志读取，本身是一个很重的过程。
第二步，把dead tuple的位置记录到内存中的dead tuple数组或者磁盘上的临时文件里，然后统一移除。移除不是简单的删除，而是把tuple在页内的空间标记为可用，并且尽量将页尾部的live tuple搬运到一起，避免页内碎片化。
第三步，更新表的统计信息（pg_statistic），方便查询规划器做准确的行数估算。这在默认配置下是vacuum附带完成的事，所以即使没有显式运行analyze，vacuum也会顺带更新一些基础统计，只是不如analyze那么全面。
第四步，更新可见性映射（Visibility Map）。这是很多文章不会细讲、但极其重要的步骤。PostgreSQL在表文件旁边会维护一个vm文件，按bit标记每个数据页是否“全页可见”。所谓全页可见，就是该页内所有live tuple对任何活跃事务都可见。这个标记对性能影响巨大——有了它，仅索引扫描（Index-Only Scan）就可以跳过堆表访问；有了它，vacuum后续再扫描该页时可以直接跳过，大幅加速清理；有了它，最关键的freeze操作才能高效推进。
2.2 vacuum full与普通vacuum的区别
很多人刚接触时会误以为“要彻底清理所以跑vacuum full”，其实这是个代价很高的选择。
普通vacuum只是把dead tuple的空间标记为可复用，并不会把空间还给操作系统。也就是说，执行之后表文件的大小可能完全不变，但里面的空洞可以被后续插入复用。这种模式胜在可以在线执行，不阻塞读写，代价是逻辑空间不会减少。
vacuum full则不同——它会新建一个表文件，把live tuple全部拷入新文件，然后删除旧文件并重建索引。效果是表物理大小被压缩到真实数据大小，空间还给操作系统。但代价是要获取表的ACCESS EXCLUSIVE锁，期间表完全不可读写，并且会消耗约等于表大小的额外磁盘空间和大量CPU/IO。
选择建议很明确：常规维护用普通vacuum，只有确认表膨胀严重且需要物理收缩时，才在维护窗口做vacuum full。日常随笔vacuum full是生产环境大忌。
2.3 freeze与事务ID回卷预防
vacuum还有一个容易被忽略的核心功能：freeze旧事务ID。前文提到事务ID最多42亿个，为了防止回卷，vacuum会把“足够老”的元组事务ID标记为冻结状态。冻结的事务ID被视为比所有事务都老，任何快照下都可见，再也不需要参与事务ID可见性判断。
PostgreSQL里控制freeze的关键参数是vacuum_freeze_min_age和vacuum_freeze_table_age。简单理解，前者是“单个元组多久没被freeze就处理”，后者是“表多久没做全表freeze就强制执行”。默认情况下，autovacuum会在事务ID推进到一定水位时自动触发freeze，但如果大量并发事务把水位推得很快，还是可能发生回卷风险。
一个实用的经验：不要随意把vacuum_freeze_min_age调得过大。默认5000万看起来挺大，但事务ID消耗速度快的系统可能几分钟就耗尽。调低了虽然会增加vacuum频率，但能有效控制风险。
2.4 HOT更新机制与vacuum的联动
PostgreSQL还有一种减少死元组的手段叫HOT更新（Heap-Only Tuple）。如果更新行时，被更新的索引键没有发生变化，并且该数据页内还有空间放新版本，那么新版本直接放在同一页内，不额外插入索引项，旧版本通过指针链关联。
这种设计使大量常见的非索引键更新完全不需要产生新的索引条目，配合真空清理时，索引扫描需要访问的旧版本大大减少。这就是为什么设计表结构时，如果某个字段会频繁更新，就尽量不要把它放进索引——否则会毁掉HOT更新的收益，让vacuum的压力成倍增加。
理解HOT机制的价值在于：vacuum不是单独作战的，考虑表设计时就应该有“减少vacuum工作量”的意识。一个频繁更新的表，如果索引设计不当，即使vacuum跑得再勤，膨胀速度也可能压不住。
3. vacuum命令实操：语法、参数与场景
3.1 核心语法与常用选项
vacuum命令的基本格式如下：
VACUUM [ ( option [, ...] ) ] [ table_name [ ( column_name [, ...] ) ] ]PostgreSQL 9.6之后推荐使用括号形式的语法，可读性和扩展性都更好。常用选项包括：
VACUUM (VERBOSE, ANALYZE) my_table;VERBOSE选项会在终端输出详细的处理过程，包括每个表的扫描页数、移除元组数、空闲空间情况等。排查问题时建议开启。
ANALYZE选项表示vacuum结束后顺带更新统计信息。production环境里对单表执行VACUUM (ANALYZE)是常见的维护操作，比分开两步跑更省时间。
FREEZE选项可以强制将表中的事务ID标记为冻结，适合在批处理导入大量数据后执行，减少后续autovacuum压力。
一个被忽视的选项是SKIP_LOCKED。如果表正被其他事务以某种锁模式占住，加上SKIP_LOCKED之后vacuum会跳过这些表而不是在那里等锁。特别是每天定时跑全库vacuum的脚本，强烈建议加上这个选项，否则遇到长事务时整个任务会卡住。
3.2 单表操作 vs 全库操作
VACUUM; -- 全库普通vacuum VACUUM (VERBOSE, ANALYZE); -- 全库vacuum+analyze，输出详细日志 VACUUM my_table; -- 只vacuum指定表 VACUUM (FULL) my_table; -- 全量压缩单表（会锁表）全库VACUUM在生产环境是可以跑的，不像有些命令会有较大副作用，但要注意CPU和IO占用。一般建议选择业务低峰期，并且开启cost-based vacuum延迟，避免对业务造成明显影响。
对于单表操作，一个实战技巧是：如果系统慢主要是某张表导致的，不要动辄全库Vacuum，只处理病根表即可。定位方法可以用pg_stat_user_tables视图看哪个表的n_dead_tup持续高位，再配合索引膨胀检测SQL来确认。
3.3 手动vacuum的时机判断
手动vacuum不该是拍脑袋的行为，建议按以下信号来判断：
- 查询pg_stat_user_tables发现n_dead_tup长期高于n_live_tup的20%，并且表上查询变慢；
- 磁盘空间告警，且确认是大表死元组占用；
- 大批量UPDATE/DELETE后，比如一次清理历史数据删除了几千万行；
- 刚导入完大量数据，事务ID推进较快，希望强制freeze；
- 表统计信息严重不准，执行计划异常，需要配合analyze刷新。
值得注意的是，vacuum本身也会消耗资源。频繁对超大表做vacuum可能产生不必要的IO和WAL日志写入。在便宜没事故和勤快出故障之间，关键靠autovacuum参数配合，这点后面单开章节。
3.4 vacuum过程观察与日志解读
使用VERBOSE选项之后，输出大概长这样：
INFO: vacuuming "public.my_table" INFO: scanned index "my_table_pkey" in 0.01 seconds: 3 pages, 10 tuples INFO: "my_table": found 5 removable, 10 nonremovable row versions in 3 out of 3 pages INFO: 0 dead row versions cannot be removed yet, oldest xid: 9181779第一行是开始处理哪张表。第二行表示扫描了多少索引页、索引元组数，如果这里扫描时间明显偏长，说明索引膨胀严重。第三行里的“removable”就是要清理的死元组数量，“nonremovable”是仍然需要保留的版本数，不可移除可能因为有active事务还在用它。最后一行的“oldest xid”是表中最早的事务ID，数值越接近2^32（约42亿）越需要警惕回卷风险。
实际排障时，我最先看的通常是“found”行里removable和nonremovable的比例。如果nonremovable常年比removable多，那么原因多半是长事务或者复制槽卡住了旧快照，单纯跑vacuum解决不了问题，必须找到并终止那个长事务。这个话题在故障排查章节详细说。
3.5 vacuum过程中锁与并发的影响
普通vacuum对并发的影响主要分两层：一是获取表的SHARE UPDATE EXCLUSIVE锁，这个锁和普通的DML不冲突，所以在线执行没问题，但与DDL操作冲突；二是vacuum扫描和清理过程中消耗IO和CPU，在高压力业务下可能影响延迟。
如果系统资源本身比较紧张，可以开启cost延迟参数让vacuum“让路”。参数为vacuum_cost_delay和vacuum_cost_limit。默认vacuum_cost_delay为0，即不限制。设置了延迟之后，vacuum每处理一定的代价就休眠若干毫秒，变相降低资源占用，但总执行时间会拉长。
对于手动执行的vacuum，可以在命令里临时指定：
VACUUM (VERBOSE, ANALYZE, DISABLE_PAGE_SKIPPING) my_table;DISABLE_PAGE_SKIPPING选项强制vacuum扫描所有页面，而不是依赖可见性映射跳过。这个选项平时没必要用，但如果怀疑visible map状态与真实数据不一致，或者刚经历过崩溃恢复，可以使用该选项做一次彻底的清理。
4. autovacuum：自动化才是生产环境的主角
4.1 autovacuum的工作机制
PostgreSQL默认开启autovacuum，由后台的autovacuum launcher进程启动worker进程执行清理。它的触发条件不是定时，而是按表内死元组数量来判断。
核心参数有两个：
autovacuum_vacuum_threshold = 50 autovacuum_vacuum_scale_factor = 0.2触发条件大约是：死元组数量 > 阈值 + 表总行数 × 比例因子。比如一张100万行的表，默认触发点是50 + 1000000 × 0.2 = 200050。也就是说，死元组超过20万才会触发autovacuum。
在很多高更新频率场景下，这个默认值偏保守。比如一张表每秒更新1000行，20万死元组只需要200秒就能堆积出来，之后autovacuum才姗姗来迟。在清空期间如果又写入大量数据，就会形成类似“先胀后清再胀”的循环，表实际的大小始终不高。
这里有个容易忽视的点：autovacuum的worker数和系统资源是有限的，如果数据库里有几百张表同时触发，可能排队。单表autovacuum跑得慢，会拖慢整体。
4.2 关键参数的调整逻辑
调整autovacuum参数，不能只是网上找一套“调优值”，必须理解每项在系统里的含义：
- autovacuum_max_workers：同时跑多少个worker。默认3，对于库多表多的实例来说偏少，可以适当调到5或更高。但注意每个worker都是一个独立的数据库连接，同时也会占用本地内存。
- autovacuum_naptime：检查触发条件的间隔，默认60秒。每次醒来要扫一遍所有库的所有表，如果表很多，检查本身也有开销。这个参数很少需要调小，反而是表特别多时可以适度调大。
- autovacuum_vacuum_cost_delay：默认2ms，即worker在清理时不会疯狂占用磁盘。这个延迟值越大会让单次vacuum变慢，但留给业务的IO越多。OLTP系统建议保持默认；如果是专门的批处理节点，可以考虑改成0或调大limit。
- autovacuum_vacuum_cost_limit：默认-1表示继承vacuum_cost_limit的值，通常是200。这个值乘以delay的配合，决定了av worker每秒大约能“消耗”多少IO代价。实际运维中，调整时要注意总和不要超过单个磁盘的IO能力。
对高更新表的单独设置也支持：
ALTER TABLE my_table SET (autovacuum_vacuum_scale_factor = 0.05); ALTER TABLE my_table SET (autovacuum_vacuum_threshold = 500);这个特性值得重视。全局参数只解决一般情况，对真正高频写入的表，单独收紧阈值比全局调低更有效，成本也更可控。
4.3 为什么很多系统还是会出现膨胀
一个常见现象：全局明明开了自动清理，长时间观察下来个别表还是膨胀严重，或者autovacuum日志显示“skipped”或花费时间特别短。
原因排查就几个方向：
第一，长事务锁住了vacuum所需的快照。vacuum无法清理比最老活跃事务更新的死元组。如果系统里有持续几小时的报表查询，或者未提交的事务长期持有连接，死元组就无法清理。这个问题必须靠业务端优化，vacuum自身无解。
第二，复制槽（Replication Slot）导致WAL无法清理，进而老版本无法判定为失效。逻辑复制或物理备库如果断连太久，复制槽卡住，主库的vacuum会连带受影响。
第三，表被ALTER TABLE等DDL锁过。autovacuum遇到无法获取锁的情况时会跳过，等下一次wakeup再尝试。如果频繁发生锁冲突，autovacuum的效果会大打折扣。
第四，worker数不够，大量表排队。常出现在表多、实例内存小的环境中，查看pg_stat_activity能看到很多autovacuum worker在同时跑，但单表进度极慢。
4.4 autovacuum与手动vacuum的取舍
这里分享我的实际经验。autovacuum更像“安全网”，目的是防事故，不是保证性能最优。它满足的是一般情况下的清理需求，但某些场景下手动vacuum依然不可替代。
大批量数据变更后的清理。一次UPDATE影响全表50%行数，autovacuum也许要等阈值到才触发，期间查询性能急剧下滑。这种场景应该手动VACUUM (ANALYZE)立刻执行。
强制freeze。autovacuum默认在事务ID达到vacuum_freeze_table_age（默认1.5亿）时才会对整个表做防回卷清理。如果业务一次性导入大量数据并占用了很多事务ID，手动FREEZE会更早释放风险。
需要物理收缩空间时。前面说的vacuum full，autovacuum永远不会执行，因为这会锁表。这类操作只能人肉在维护窗口做。
所以合理的策略是：autovacuum保持默认或者略微调紧，作为兜底；大型变更、敏感操作之后手动vacuum；定期检查膨胀和事务ID水位。
5. 常见问题与排查技巧
5.1 事务ID回卷风险判断
PostgreSQL里判断回卷风险最直接的SQL：
SELECT datname, age(datfrozenxid) AS xid_age FROM pg_database ORDER BY xid_age DESC;age()函数返回最老未冻结事务ID到现在经过了多少事务。当这个值接近2^31（约21亿）时，控制台会出现警告；继续增长到2^32附近时，数据库会强制停止所有读写，进入紧急保护模式。
规避措施只有一个核心思路：确保vacuum正常执行，并且将表的datfrozenxid前移。如果一张表长期不经完整vacuum，它的datfrozenxid会非常旧，全库回卷风险也主要来自这类表。
定位哪些表拉高了全库风险：
SELECT relname, age(relfrozenxid) AS xid_age, n_dead_tup FROM pg_class c JOIN pg_stat_user_tables s ON c.oid = s.relid ORDER BY xid_age DESC LIMIT 10;5.2 膨胀检测与定位
检测表膨胀常用的方法是比较实际大小和逻辑估算大小：
SELECT schemaname || '.' || relname AS table_name, pg_size_pretty(pg_total_relation_size(relid)) AS actual_size, pg_total_relation_size(relid) - pg_relation_size(relid) AS index_size FROM pg_stat_user_tables ORDER BY pg_total_relation_size(relid) DESC;更精确的方式是使用pgstattuple扩展：
CREATE EXTENSION pgstattuple; SELECT * FROM pgstattuple('my_table');其中的dead_tuple_percent字段就是死元组占比。如果这个值长期超过20%，说明autovacuum没有及时跟上，需要按第4章的方法调整。还有一种特殊情况是“dead_tuple_percent很高，但autovacuum没有触发”，这时要查一下表的reloptions里是否设置了autovacuum_enabled = off。
索引膨胀也是隐蔽问题。主表和索引都占用磁盘，但索引没有dead tuple概念，它的膨胀是因为索引页删除的条目没有物理回收。这里可以用这个经典SQL：
SELECT indexrelname, pg_size_pretty(pg_relation_size(indexrelid)) AS idx_size, idx_scan, idx_tup_read FROM pg_stat_user_indexes ORDER BY idx_scan DESC;如果一个索引的idx_scan长期为0或者非常小，同时占用空间又大，可以考虑删除重建或者确认是否真的还需要。
5.3 vacuum运行速度异常慢
有时候vacuum跑得极慢，几百万行的表跑了半小时没结束。常见原因和对策：
- 开启了cost delay，而且值偏大。查看当前vacuum进程在pg_stat_activity里的wait_event，如果大量时间在wait，说明在休眠让路，适当调高cost limit能加速。
- 长事务导致大量无法清理的版本。真空处理时要遍历所有事务状态判断元组可见性，长事务越多，判断成本越高。
- IO瓶颈。vacuum本质是大量随机读和顺序写，磁盘是机械盘还是SSD差别巨大。如果系统io_util已满，vacuum自然慢。
- 系统内存紧张导致排序和可见性映射失效。检查系统dmesg是否有OOM相关迹象。
定位这些问题的第一步，都是开启VERBOSE重跑一遍，观察输出日志中每个阶段消耗的时间位置，再对症处理。
5.4 死锁与锁等待的问题
很多人可能没有意识到，vacuum会参与死锁和锁等待。autovacuum在获取SHARE UPDATE EXCLUSIVE锁时，如果遇到ALTER TABLE或CREATE INDEX等获取ACCESS EXCLUSIVE锁的操作，两者可能互相等待。
当autovacuum worker拿到锁并开始清理后，如果业务DDL一直等在那里，那么DDL后面的其他查询也会堆积。表现就是系统突然卡顿。处理方式是观察pg_stat_activity，找到那个“占用锁+等待锁”的关系链，做出决策。
实际运维里有一个经验：如果DDL无法结束并且涉及的表很大，不要直接在锁等待时硬刚。先取消DLL事务，让autovacuum完成几轮清理，再挑低峰期执行DDL。
5.5 快速上手排查脚本
最后分享一个我常用的综合排查组合，判断当前系统的清理健康状况：
-- 1. 查看当前正在运行的vacuum进程 SELECT pid, datname, query, state, wait_event_type, wait_event FROM pg_stat_activity WHERE query LIKE '%vacuum%' AND query NOT LIKE '%pg_stat_activity%'; -- 2. 查看各表死元组和未清理情况 SELECT schemaname, relname, n_live_tup, n_dead_tup, last_autovacuum, last_vacuum FROM pg_stat_user_tables ORDER BY n_dead_tup DESC LIMIT 10; -- 3. 查看全局事务ID水位 SELECT datname, age(datfrozenxid) FROM pg_database ORDER BY 2 DESC;这套SQL组合能快速回答三个问题：vacuum现在跑没跑、哪些表积压严重、有没有回卷风险。在日常巡检中用起来很顺手。
最后
在小团队或者单实例数据库环境里，vacuum的坑往往不是配置有多难，而是没人把它当回事。等磁盘报警、监控变红才开始排查，压力大得多。与其那样，不如现在就动手把系统里那些“看起来不用管”的表翻一遍，跑一遍诊断SQL，确认事务ID水位和死元组数量。技术上的东西不复杂，复杂的是坚持做日常维护的习惯。希望这篇命令详解能帮你在下一次vacuum相关的问题面前，少走一点弯路。
