PostgreSQL数据库vacuum使用方法：六六云自管库怎样验冻结与回卷预算

服务器还有空闲内存，数据库的事务年龄却持续上升；一旦逼近保护边界，应用可能连新写入都无法开始。此时直接给六六云实例加核、扩盘，未必能让风险下降。PostgreSQL的冻结维护要处理的是旧事务编号的可比较范围，判断采购是否有效，需要同时看年龄增长、冻结进展和维护期间的业务延迟。下面以自管数据库为前提，把可以现场核对的指标、时间预算和商家交付问题放到一起；没有任何六六云实测数据，也不把线路宣传当作数据库性能证明。

先分清“没有垃圾行”和“已经完成冻结”

PostgreSQL常规VACUUM既涉及回收旧行版本，也承担防止事务编号回卷的工作。事务编号的比较有范围，系统需要把足够旧的行版本视为对所有后续事务可见，避免长期运行后出现新旧身份混淆。因而，一张数据基本不再修改的历史表，仍然可能需要冻结；只盯删除量、死元组数量或磁盘占用，会漏掉另一条维护义务。

官方第18版维护文档区分了可见性图中的全部可见与全部冻结状态。普通扫描能够跳过一些页面，并不意味着表的冻结边界已经向前推进。文档明确指出，只有扫描了所有可能含有未冻结事务编号的页面，表的relfrozenxid才会得到相应推进。业务查询不报错、自动维护进程存在、上一次维护时间有更新，这些都只能作为线索，不能单独作为冻结成功的验收结果。

从整个实例找最旧的对象，而非只看最忙的表

先查询pg_database中的age(datfrozenxid)，识别各数据库的事务年龄；进入年龄偏大的数据库，再按age(relfrozenxid)检查普通表、物化视图及其关联的TOAST存储。不要只检查应用列表里最大的主表。某个冷表、附属存储或系统目录一直未被处理，也可能成为数据库边界难以前移的原因。查询权限不足时，应在采购交付清单中写明由谁执行、谁解释结果。

年龄的单位是消耗的事务编号，不是小时，也不是接口请求次数。一次请求可以产生多个数据库事务，而只读活动与编号分配的关系又取决于实际执行。用事务年龄的连续采样差值估计消耗速度，比拿网站访问量直接换算可靠。记录采样时间、数据库身份和重启迁移情况，避免把来自不同实例的数值拼成一条趋势。这里讨论的XID预算也不覆盖多事务编号的全部风险，相关年龄仍需另设监控。

把报警线换算成可操作的维护窗口

假设运维团队为某次演练自行设定5亿的内部干预年龄，当前最旧年龄是1.6亿，采样观察到每秒消耗2000个编号，则剩余内部预算为3.4亿，除以每秒2000，再除以每天86400秒，约为1.97天。若本次完整维护在相近负载下需要10小时，扣除维护本身只余约1.55天。以上均为假设计算，5亿不是官方默认值，不是安全保证，更不能当作全体数据库统一适用的报警线。

可执行的采购门槛是：到内部干预线的时间，应覆盖排队等待、故障确认、实际维护、失败重做以及业务允许的变更窗口。增长率明显波动时，按高峰区间重新计算；一次采样差值很小，也不能证明活动促销期间仍有相同余量。维护刚完成后，还应确认最旧年龄确实下降，再观察后续增长速度，而非仅把工单状态改为已处理。

这一公式可以帮助决定是否需要临时更高磁盘性能或独立维护实例，但必须先证明维护处在资源受限状态。如果任务一直等待锁，或者旧事务妨碍边界前移，购买更多CPU无法直接解除它。相反，确认扫描持续进行且存储等待占主导，才有理由把磁盘能力、共享争用和可扩容方式列为询价重点。不能仅凭“配置更高”推定10小时会缩成5小时。

不要把最大年龄参数当成延期按钮

官方文档说明，表达到autovacuum_freeze_max_age相关条件后，会触发防回卷维护；其目的包含强制推动必要工作。调高阈值只是改变触发时点，不会自动清除旧编号，也没有增加底层可比较范围。关闭普通自动维护同样不能作为取消防回卷义务的手段。应先读取当前版本的配置、表级覆盖项和任务日志，再判断具体触发原因，避免照搬另一实例的参数。

PostgreSQL官网当前发布信息显示，14版本将在2026年11月12日停止接收修复，并提醒生产用户规划升级。版本迁移使维护责任更值得提前检查，但升级与冻结是不同工作：换成受支持版本，不代表旧数据的维护自动完成。本篇据第18版文档解释机制；运行其他大版本时，必须对照对应版本的参数和进度视图，不把文档差异当成商家故障。

观察维护是否前进，再决定加资源还是处理阻挡

维护执行期间，可以结合pg_stat_progress_vacuum观察当前阶段、已扫描的堆页面及总页面等字段。进度视图是定位工具，扫描计数增加不等于所有对象已经完成冻结，也不应把单次百分比简单外推成最终完成时刻：索引处理、不同页面密度和同时发生的业务负载都会改变剩余耗时。把相同对象的进度、I/O等待、业务响应分位数及年龄变化一起记录，才适合做升档前后对照。

若日志显示维护反复被取消，要找出取消者及其原因。若某个会话长期不结束，先核对它的业务归属及backend_xid、backend_xmin等信息；预备事务与复制槽也有各自的确认和处置责任。不要为了让图表变绿而批量终止会话或删除槽。删除仍被副本使用的复制槽，可能迫使副本重建；处理预备事务需要业务协调结果，不能仅凭创建时间决定提交或回滚。

官方文档对接近回卷保护边界的应急恢复有明确限制：在拒绝分配新事务编号的情形，应处理旧预备事务、长期事务和相关复制槽，再按文档进行普通VACUUM。不要在此时把VACUUM FULL或强制FREEZE当成通用急救命令。前者需要事务编号并增加风险，后者可能做超出恢复正常运行最低要求的工作。常规预防性冻结与已经进入保护状态的应急操作，必须分开制定方案。

六六云的网络卖点，怎样转成数据库采购边界

本次渠道通实时返回六六云的推广入口，官网首页可打开，标注海外多个地区、原生IP和若干回程线路。首页的地区起价只是入口信息，具体选购页本次读取超时，渠道通商品表也未提供可用于逐档核对的六六云商品。因此这里不列未经配对核实的CPU、内存、磁盘价格，不宣称任何套餐已经适合上述负载。首页所述网络属性也不能证明磁盘同步延迟、持续维护吞吐或数据库托管责任。

如果应用和数据库确有同地区部署需求，且准备自行管理PostgreSQL，可以通过推广入口查看六六云多地区原生IP服务器的当前配置与可选节点。这是推广链接。选择前先要到实际套餐清单，并确认该节点的磁盘类型、存储是否共享、持续I/O约束、扩盘后是否涉及停机，以及系统权限能否完成监控与维护。未获得这些回答前，线路名称只能用于网络候选筛选。

六六云首页还写有7×12小时技术支持，但这不能解释为数据库全天候代维。按前述假设，内部预算不足两天时，响应时段和维护执行人的安排就会直接影响可用窗口。自管团队能够持续监测、独立处理数据库任务，且压测证实维护期间业务延迟可接受，才适合把此类云服务器作为候选。要求供应商接管数据库应急、没有值守人员，或者主要瓶颈已经是存储长时间等待的团队，应先确认服务范围，不能用住宅IP权益替代管理能力。

下单前，把这些问题写成能交付的答案

要求商家说明订单对应的vCPU使用政策及磁盘持续I/O限制，避免维护一启动就触发公平使用边界；要求明确扩容是否更换宿主或IP、是否能保留原盘、回退有什么条件；再确认工单受理时间、硬件故障与数据库故障的责任分界。首页提到的退款表述仍需结合当前服务条款、支付方式与适用套餐确认，不宜先付长周期费用再追问适用范围。

采购成本应把实例费用、独立备份存储、演练用临时实例、传输费用及值守时间分别列出。冻结维护本身不等于产生可恢复备份，磁盘快照也需核对一致性和恢复路径。没有具体订单及实际维护吞吐，这些项目无法合成可信总价。准备好数据量、最旧年龄趋势和维护日志后，可用推广入口核对六六云候选节点的配置、扩容方式与实际账期报价，把询价结果写入预算；同一入口不代表每个地区拥有相同限制。

最终验收可以落在一份记录上：维护前后的最旧年龄、任务处理的对象、连续进度、期间业务延迟，以及下一次触发前剩余时间。若年龄没有按预期回落，就继续核查遗漏对象和阻挡条件；若年龄下降但业务无法承受维护负载，再讨论资源隔离或更高性能存储。能把这份记录持续交接，才有依据决定这台服务器继续运行、调整规格，还是更换部署方式。

资料来源

PostgreSQL常规维护与事务编号回卷文档；PostgreSQL自动维护与冻结配置；PostgreSQL维护进度视图说明；PostgreSQL官方版本发布与支持提醒；六六云官网当前节点与服务说明