调优 · XB 现场笔记

部分索引的写入成本

Tue, 15 Feb 2028 00:00:00 +0000

部分索引筛选的是行，不是裁剪列。给 id 建索引并加上 WHERE status = 'open'，保存的是未关闭行的标识符；状态列决定哪些行进入索引，却不因此成为搜索键。估算维护成本时，这个区别很重要：即使某一列的值没有存进索引键，它仍可能影响更新需要付出的代价。

如果订单表大部分是已关闭的历史记录，把这些行排除在索引之外，确实可能省下大量索引空间。但这不代表历史行可以免费写入，也不保证查询一定更快，更不会消除数据表本身的清理工作。判断收益时，要同时看结构缩小了多少，以及维持正确状态仍需承担哪些写入。

区分成员资格与更新成本

新插入的行不满足谓词时，这一个部分索引不需要为它新增条目。谓词判断、表内存储、其他索引以及正常事务处理仍然存在。把一行从子集外改到子集内，需要新增条目；把它改出子集，则会改变当前查询能看见的成员。旧行版本与过时索引条目的物理回收可能发生在之后，不能把逻辑上退出子集理解成立即释放所有存储空间。

成员资格没有变化，也不等于可以跳过索引维护。未关闭订单的标识符改变了，索引键就需要更新。即使只修改一列与索引无关的备注，只要数据库无法采用堆内元组更新，也就是 HOT，新行版本仍可能需要新的索引条目。因此，“谓词结果不变”不足以证明这次更新很便宜。

对本文讨论的 PostgreSQL 18 B-tree 索引，HOT 要求所有索引定义引用的列值保持不变，包括表达式引用的列和部分索引谓词引用的列；原来那张堆页面还必须容得下新行版本。把状态从已关闭改成已归档，两种状态虽然都不满足谓词，仍然改变了索引依赖的状态列，会阻止 HOT。只修改没有被任何索引引用的备注列，则可能满足条件。

降低表的填充比例可以为页面内更新预留空间，但不是保证成功的开关。检查时必须看整张表的索引集合，另一个索引可能恰好引用备注列，独立阻止这次优化。只盯着准备新增的那个部分索引，会漏掉其他定义施加的限制。

规则还依赖版本和索引方法。PostgreSQL 16 开始允许只改变 BRIN 等汇总索引引用列的更新使用 HOT，汇总信息仍可能需要维护。这项例外不适用于这里的 B-tree 索引。把一个版本、某种索引上的测试结论搬到其他部署之前，应先核对对应版本的文档。

可以使用与值得使用是两回事

规划器必须能够证明，查询条件蕴含部分索引的谓词。只包含未关闭订单的索引，不能单独回答还可能需要已关闭订单的请求。通用计划里的 status = $1 无法提供这个证明；按具体参数生成的定制计划则可能知道传入值。若状态条件本来就是固定的 status = 'open'，仅把其他查询值参数化，并不会抹掉这个事实。

有资格参与选择的索引，仍要与其他访问路径比较成本。表很小或者结果覆盖面很广时，顺序扫描可能更合适。看到计划没有采用部分索引，先检查估算行数、实际行数与缓冲区访问，再判断是不是谓词写法导致无法匹配。机械要求计划永远出现某个索引名，会把性能假设误当成正确性要求；结果是否完整正确与路径是否足够便宜，应该分别验证。

坏掉的样子

积压越来越多，原本很小的未关闭子集也可能占据大部分数据；频繁的状态切换，还可能抵消预期的写入节省。应使用有代表性的查询和状态转换比较，而不是只凭两个索引的体积推导吞吐量。大量重叠的部分索引会增加规划与维护工作，不能把每个报表的过滤条件都独立变成一个索引。

新增切片或删除看起来没人扫描的索引之前，要检查完整索引集合与业务规则。尤其是承担唯一性约束的索引，即使查询扫描次数很低，也可能一直在保护数据完整性。体积变大或扫描次数减少，意味着需要重新评估，不是可以直接删除的充分证据。

快速验证

在可丢弃的 PostgreSQL 18 数据库中，打开一个新的 psql -X -v ON_ERROR_STOP=1 会话，并确认已启用 track_counts，依次运行两个代码块。下面的 SQL 已在 PostgreSQL 18.6 的无套接字单用户模式中执行；尚未验证客户端连接服务器的路径。临时表共有两万行，其中两百行未关闭。显式命名索引，避免依赖数据库自动生成的名字。

BEGIN;
CREATE TEMP TABLE partial_cost_demo (
 id integer NOT NULL,
 status text NOT NULL,
 note integer NOT NULL
) WITH (fillfactor=50);
INSERT INTO partial_cost_demo
SELECT g, CASE WHEN g % 100 = 0 THEN 'open' ELSE 'closed' END, 0
FROM generate_series(1,20000) AS g;
CREATE INDEX cost_all_id ON partial_cost_demo (id);
CREATE INDEX cost_open_id ON partial_cost_demo (id) WHERE status='open';
ANALYZE partial_cost_demo;
SELECT pg_relation_size('cost_all_id') AS full_bytes,
 pg_relation_size('cost_open_id') AS partial_bytes;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF)
SELECT id FROM partial_cost_demo WHERE status='open' ORDER BY id LIMIT 5;
SELECT id FROM partial_cost_demo WHERE status='open' ORDER BY id LIMIT 5;

查询结果应为一百、两百、三百、四百和五百。部分索引预计占用更少字节，但不要要求体积精确等于全量索引的百分之一，页面本身也有开销。记录实际选中的计划，不要断言某一种固定形状。全量索引与部分索引使用同样的键，提供体积对照，同时也会参与访问路径竞争。

UPDATE partial_cost_demo SET note=1 WHERE id=100;
SELECT n_tup_upd, n_tup_hot_upd FROM pg_stat_xact_user_tables
WHERE relid='partial_cost_demo'::regclass;
UPDATE partial_cost_demo SET status='archived' WHERE id=101;
SELECT n_tup_upd, n_tup_hot_upd FROM pg_stat_xact_user_tables
WHERE relid='partial_cost_demo'::regclass;
SELECT count(*) FROM partial_cost_demo WHERE status='open';
ROLLBACK;

这里使用当前事务的统计视图，计数会随本事务中的操作持续更新，不必等待累计统计刷新。更新总数应从一次增加到两次。备注更新可能增加 HOT 次数；状态改变不应增加 HOT 次数，即使它前后都不属于未关闭子集。隔离测试中，两次记录的更新总数与 HOT 次数分别为（一，一）和（二，一），未关闭行仍有两百行。全量和部分索引的大小分别为四十六万六千九百四十四与一万六千三百八十四字节，选中的仅索引扫描仍访问了五次堆。这里记录的是特定实验的观察值，不是所有环境都应相同的结果。回滚后实验对象和数据已被移除。

这个练习把索引子集大小与 HOT 条件分开观察，并没有测量长期运行的生产负载。临时表上的耗时不能证明生产 WAL 节省，也不能证明持续写入吞吐量。真正的上线判断还需要同等负载、同等索引集合，以及有代表性的页面空间和更新分布。

来源

PostgreSQL 18 部分索引，成员资格、逻辑蕴含与过量部分索引，已核验 2026-10-15。
PostgreSQL 18 HOT，更新条件与页面空间，已核验 2026-10-15。
PostgreSQL 18 HOT 实现说明，谓词列依赖和元组链，已核验 2026-10-15。
PostgreSQL 16 发行说明，第十六版引入的 BRIN 例外，已核验 2026-10-15。
PostgreSQL 18 PREPARE，定制计划与通用计划，已核验 2026-10-15。
PostgreSQL 18 统计系统，当前事务的统计计数，已核验 2026-10-15。
PostgreSQL 18 EXPLAIN，实际执行与缓冲区测量，已核验 2026-10-15。
PostgreSQL 18 体积函数，关系主数据分支的大小，已核验 2026-10-15。

自动清理资格不等于执行完成

Fri, 04 Feb 2028 00:00:00 +0000

繁忙表持续产生旧行版本，维护速度需要与这种产生速度匹配。降低自动回收门槛，可以让表更早具备被处理的资格，但“符合条件”并不等于“已经完成”。工作者仍需轮到这张表、获得所需锁，并在积压继续增长之前完成足够的有效清理。调优应观察这个完整循环，不能把一个参数值当成后台吞吐的保证。

坏掉的样子

普通更新和删除的触发条件，由固定门槛加上表行数估计乘比例因子构成；PostgreSQL 18 在启用上限时，还会应用最大触发门槛。插入触发清理、由事务年龄驱动的冻结，又有各自的运行原因。因此，只看一个死元组比例，会漏掉其他维护需求；每看见一次清理就断言更新删除门槛被触发，也可能误判真正原因。

把门槛调低，不能释放仍被旧快照需要的版本，也不能创造额外的磁盘吞吐。增加工作者或降低成本延迟，还可能加剧与前台查询的资源竞争。让死元组估计在每个瞬间都接近零，既不是通用的现实目标，也不能充分说明业务性能良好。真正需要维持的是可持续的清理能力、可接受的文件增长、请求延迟和维护成本。

快速验证

本轮没有重跑原样保留的后台工作者集成。先前的自动清理观察属于历史记录，手动或单用户清理不能代替它。

使用 PostgreSQL 18 可丢弃实例，确认自动回收与统计收集已启用、有可用工作者，并使用正常的一分钟数据库检查间隔。通过一个全新的 psql -X -v ON_ERROR_STOP=1 连接执行下面的脚本。它最多等待一百三十秒，核对真实自动执行；如果超时，应把这次观察记为失败，不能手动清理一次就冒充自动任务已经运行。

CREATE SCHEMA churn_demo;
CREATE TABLE churn_demo.jobs (id integer PRIMARY KEY,n integer)
 WITH (autovacuum_enabled=false,
 autovacuum_vacuum_threshold=50,
 autovacuum_vacuum_scale_factor=0.2);
INSERT INTO churn_demo.jobs SELECT g,0 FROM generate_series(1,10000) AS g;
SELECT pg_stat_force_next_flush();
VACUUM (ANALYZE) churn_demo.jobs;
UPDATE churn_demo.jobs SET n=1 WHERE id<=1000;
SELECT pg_stat_force_next_flush();
SELECT n_live_tup,n_dead_tup,vacuum_count,autovacuum_count
FROM pg_stat_user_tables WHERE relid='churn_demo.jobs'::regclass;
SELECT 50+0.2*reltuples AS old_threshold,50+0.01*reltuples AS new_threshold
FROM pg_class WHERE oid='churn_demo.jobs'::regclass;
ALTER TABLE churn_demo.jobs SET
 (autovacuum_enabled=true,autovacuum_vacuum_scale_factor=0.01);
DO $$
DECLARE deadline timestamptz := clock_timestamp()+interval '130 seconds';
BEGIN
 LOOP
 PERFORM pg_stat_clear_snapshot();
 EXIT WHEN (SELECT autovacuum_count>0 FROM pg_stat_user_tables
 WHERE relid='churn_demo.jobs'::regclass);
 IF clock_timestamp()>deadline THEN
 RAISE EXCEPTION 'no automatic vacuum observed within the experiment budget';
 END IF;
 PERFORM pg_sleep(0.25);
 END LOOP;
END $$;
SELECT pg_stat_clear_snapshot();
SELECT n_dead_tup,last_autovacuum IS NOT NULL AS ran,autovacuum_count>0 AS counted
FROM pg_stat_user_tables WHERE relid='churn_demo.jobs'::regclass;
SELECT count(*),count(*) FILTER (WHERE n=1) FROM churn_demo.jobs;
DO $$ BEGIN
 IF (SELECT count(*) FROM churn_demo.jobs)<>10000
 OR (SELECT count(*) FROM churn_demo.jobs WHERE n=1)<>1000 THEN
 RAISE EXCEPTION 'maintenance changed application data';
 END IF;
END $$;
DROP SCHEMA churn_demo CASCADE;

测试表最初只关闭自己的常规自动回收，让初始化与受控更新先完成。手动清理并分析建立统计，同时清掉初始化插入积压，然后再更新一千行。显式统计刷新调用用于同步这个短实验，避免待发布的写入增量落在手动维护更新估计值之后；它不是建议在线业务频繁调用的调优开关。

启用工作者之前，预期存活和死亡元组估计分别为一万和一千，手动清理计数为一，自动清理计数为零。应用数据的准确行数会另外查询核对，不能用估计值取代。固定门槛设为五十时，原比例得到两千零五十，新比例得到一百五十。测试表很小，最大门槛在这里不构成限制，因此可以直接看清比例变化带来的资格差异。

一千个旧版本已经超过新的门槛。脚本随后开启这张表的常规自动回收，并只降低它自己的比例因子，再等待自动计数增加。轮询块每次丢弃统计缓存，避免在同一个观察事务中反复读取旧快照。开启工作者之后，脚本没有再次执行手动清理，所以最终的自动计数必须来自真实后台工作，而不是被实验自己的命令伪造出来。

最后预期死亡元组估计为零，自动清理时间非空，自动计数为正。业务数据仍有一万行，且恰好一千行的值已更新为一。本次测试实例在预算内观察到了后台任务完成，但具体等待时间取决于调度相位和工作者可用情况。因此，断言检查的是事件是否发生与数据是否保持正确，而不是固定等待多少秒就一定成功。

找到真正限制清理的阶段

如果一直没有自动执行记录，应检查表级有效选项、服务器自动回收设置、统计收集、工作者活动和冲突锁。手动维护时间不能代替自动维护时间。如果工作者确实完成了任务，但旧版本仍然保留，应检查长事务和其他可见性边界。如果版本已经允许移除，却产生得比处理更快，才需要进一步评估资源容量、成本节流和写入方式。

针对某张大而繁忙的表调整比例，通常比全局改变所有表更有针对性。修改前保留原选项，在具有代表性的多个负载时段里比较维护计数、文件增长与业务延迟，不能只用一次短暂空闲期得出结论。业务状态、表规模和写入模式改变以后，也应重新评估或恢复覆盖设置。

实验最后删除自己的整张表，所以不会留下调参结果；真实表的配置则需要明确维护。即使更新流量后来降低，事务年龄与冻结需求仍然存在，不能因为死元组图表安静了就长期关闭后台工作。触发资格、执行记录、清理效果和前台代价同时得到验证，才足以判断这次调校是否有效。

来源

PostgreSQL 18 自动回收配置，门槛、比例、工作者限制与检查间隔，已核验 2026-10-15。
PostgreSQL 18 常规清理，触发公式及不同维护目的，已核验 2026-10-15。
PostgreSQL 18 累计统计，手动和自动计数及统计缓存，已核验 2026-10-15。
PostgreSQL 18 统计函数实现，实验用于同步观察的刷新辅助函数，已核验 2026-10-15。

查询变慢时同时检查计划与等待

Mon, 31 Jan 2028 00:00:00 +0000

一条过去很快的查询，可以在数据、统计和访问计划都没有变化时变慢。另一个事务可能持有它需要的锁，存储缓存可能比上次更冷，应用也可能在语句进入 PostgreSQL 之前就开始等待。重新检查计划很有用，但它应当放在完整的耗时比较中：先区分时间是花在执行工作上，还是花在等待获得执行机会。不能从“现在更慢”直接推导出“数据与统计一定都变了”。

保留可比较的基线

记录语句形状、有代表性的参数值、返回行数、相关会话设置，以及应用是否使用预备语句。不同参数可能命中完全不同规模的数据。手工使用常量的查询，不一定复现预备语句采用的通用计划；不同角色或搜索路径，也可能改变实际对象与权限。因此，拿一条看起来相似的语句作为对照，并不保证比较条件相同。

尽量在变慢正在发生时观察活动。pg_stat_activity 可以显示一个状态为运行中的查询正在等待锁；运行中并不等于持续消耗处理器。pg_blocking_pids 列出当前阻塞这个后端的会话。查看其他角色活动需要适当权限，因此字段不可见不等于没有工作发生。交互观察最好使用新的自动提交查询，而不是在同一个长事务中不断读取已经缓存的监控快照。

坏掉的样子

不加判断就运行 ANALYZE，相当于把每次变慢都当成统计陈旧。它可能增加维护工作，却完全没有解除真正的阻塞。一张只有一行的表，即使新增索引，也不能释放其他事务持有的行锁。准确的行数估计和很小的顺序扫描，可以与很长的应用等待同时存在；这两种观察并不矛盾。

EXPLAIN ANALYZE 会真正执行语句，写入也不例外，而且测量本身同样可能被阻塞。从生产环境复制一条大范围更新，不是无害的检查。应先看等待情况和锁的拥有者，再选择安全夹具或副作用已经明确的语句来测量。看到某个进程编号出现在阻塞列表中，也不能立即终止不熟悉的事务，因为它可能正在完成另一个有效业务操作。

没有锁等待的计划样本，也不等于端到端延迟。EXPLAIN ANALYZE 不会像普通查询那样把结果行发送给客户端；未指定 SERIALIZE 时，还不包含输出转换。TIMING OFF 减少逐节点计时开销，但仍保留总执行时间。大量结果传输、应用解码和连接池排队，需要在计划之外单独观察，不能从这里的执行时间中直接读出。

快速验证

打开三个新的 psql 会话，分别记作甲、乙、丙，连接同一个可丢弃的 PostgreSQL 18 数据库并使用相同角色，保留通常的自动提交行为。名为 query_recheck_demo 的模式必须尚不存在。务必区分会话：把所有代码块顺序粘贴到同一个连接，无法证明事务之间的阻塞。

在甲中建立夹具，然后开启事务，修改唯一一条记录但暂不提交。

\set ON_ERROR_STOP on
CREATE SCHEMA query_recheck_demo;
CREATE TABLE query_recheck_demo.items (id integer PRIMARY KEY,value integer);
INSERT INTO query_recheck_demo.items VALUES (1,0);
ANALYZE query_recheck_demo.items;

BEGIN;
UPDATE query_recheck_demo.items SET value=10 WHERE id=1;
SELECT pg_backend_pid() AS blocker_pid;

在乙中发起带执行测量的更新。它会等待甲结束事务，或者等到六十秒的语句超时。

SET application_name='xbcatm_recheck_waiter';
SET statement_timeout='60s';
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF)
UPDATE query_recheck_demo.items SET value=value+1 WHERE id=1;

乙仍在等待且尚未超时时，在丙中执行观察查询。实验专用应用名称用于定位乙，不需要展示整条查询文本。

SELECT pid,state,wait_event_type,wait_event,pg_blocking_pids(pid) AS blockers
FROM pg_stat_activity WHERE application_name='xbcatm_recheck_waiter';

回到甲，撤销尚未提交的变更并释放锁，然后收集乙执行完毕后的计划。

ROLLBACK;

确认乙已经成功结束后，在丙中检查最终数据并清理夹具。

SELECT value FROM query_recheck_demo.items WHERE id=1;
DROP SCHEMA query_recheck_demo CASCADE;

原文记录的 PostgreSQL 18.6 观察未在本轮重新执行，其中乙的状态为运行中，等待类型是 Lock，具体等待事件是 transactionid，阻塞列表包含甲的进程编号。具体事件可能随争用过程变化，核心证据是乙确实被甲阻塞。甲回滚后，乙把原本的零加成一，最后查询返回一，清理语句移除了整个实验模式。

乙的扫描估计并读取一行；最上层 Update 节点实际返回零行，是因为没有 RETURNING 子句，不表示没有修改数据。总体执行时间包含人为制造的等待，长短取决于甲何时释放事务，不能把这个数字当作扫描一行的固有成本。如果乙先超时，就先回滚甲，并用丙的最后一个代码块清理夹具后再重新开始。取消的更新并不等同于成功加一，不能沿用成功情况的结果解释。

顺着观察到的原因继续

如果证据指向锁等待，先调查事务持有时间和归属，再考虑访问路径。如果实际处理的行太多，则比较过滤选择率与当前统计。如果排序或哈希操作发生溢写，就检查内存和临时读写。最后还要把数据库执行时间与应用请求延迟比较，识别连接建立、连接池排队或客户端处理的部分。只有新计划能够解释测得的回归，并保持所需结果，计划变化才构成有效改进。

来源

PostgreSQL 18：监控数据库活动，活动会话与等待观察，已核验 2026-10-15。
PostgreSQL 18：使用 EXPLAIN，行数、循环次数与计划解读，已核验 2026-10-15。
PostgreSQL 信息函数，通过 pg_blocking_pids 识别阻塞会话，已核验 2026-10-15。

VACUUM FULL 重建一张表而不是修剪

Mon, 03 Jan 2028 00:00:00 +0000

大量删除之后，PostgreSQL 表可能只剩少量记录，却仍保留很大的文件。普通清理让旧空间可以在表内复用，完全清理则把存活内容写入新文件，同时重建索引。更彻底的空间回收，需要另一套锁与容量预算，应作为有计划的维护操作，而不是一看到文件大小偏高就立刻执行的日常反应。

坏掉的样子

重写需要的是 ACCESS EXCLUSIVE 表锁，普通读取和写入都与它冲突。某个查询虽然已经执行完，但事务仍然打开、继续持有表锁，也会挡住重写。把它叫成独占行锁，或者以为只有写请求受影响，会低估实际中断范围。排队等待重写的强锁请求，还可能影响随后进入的其他取锁请求，不能只看当前命令有没有开始复制数据。

替代文件成功建立之前，原文件仍然存在，所以操作需要额外磁盘空间。等文件系统已经写满才着手完全清理，可能反而没有容纳新文件的余量。应提前评估替代堆表与索引、磁盘读写和日志影响，以及能够承受的持锁时长。常规自动回收不会自动替你执行这类完整重写。

快速验证

在同一个 PostgreSQL 18 可丢弃数据库中，开启甲、乙两个全新的 psql -X -v ON_ERROR_STOP=1 会话。清理命令必须在显式事务块之外执行。乙先创建五千行、删除前四千五百行，然后进行普通清理：

CREATE SCHEMA compact_demo;
CREATE TABLE compact_demo.items (id integer PRIMARY KEY,payload text)
 WITH (autovacuum_enabled=false);
INSERT INTO compact_demo.items
SELECT g,repeat(md5(g::text),10) FROM generate_series(1,5000) AS g;
CREATE TABLE compact_demo.baseline AS
SELECT pg_relation_size('compact_demo.items') AS heap_bytes,
 pg_relation_filenode('compact_demo.items') AS file_id;
DELETE FROM compact_demo.items WHERE id<=4500;
VACUUM (ANALYZE) compact_demo.items;
SELECT pg_relation_size('compact_demo.items')=heap_bytes AS same_heap_size,
 pg_relation_filenode('compact_demo.items')=file_id AS same_file
FROM compact_demo.baseline;

两个比较都返回真：堆文件大小与文件标识没有改变。存活行位于原文件尾部，末尾不存在可以截断的连续空页，所以普通清理不能通过截断来缩小这个特定文件。这不代表普通清理永远不会缩文件；如果末尾确实存在可释放的空页，就可能归还相应空间。这里要区分样本布局和命令的一般能力。

甲读取剩下的五百行，并保持事务打开：

BEGIN;
SELECT count(*) FROM compact_demo.items;

甲没有执行任何更新，但仍持有对应表锁。乙给重写设置很短的取锁预算，避免实验无期限等待：

SET lock_timeout='100ms';
\set ON_ERROR_STOP off
VACUUM (FULL) compact_demo.items;
\echo full_state :SQLSTATE
\set ON_ERROR_STOP on
RESET lock_timeout;

预期得到 55P03。已有读事务阻止了更强表锁的获取。临时允许这次预期错误继续显示，是为了核对结果和完成清理；随后恢复会话原来的超时设置。这个毫秒预算只是实验值，不是对实际维护窗口的参数建议，也不能据此推算大表重写需要多长时间。

甲现在结束读事务，释放它持有的锁：

COMMIT;

乙可以执行重写，再检查存储标识和所有保留字段：

VACUUM (FULL,ANALYZE) compact_demo.items;
SELECT pg_relation_size('compact_demo.items')<heap_bytes AS smaller_heap,
 pg_relation_filenode('compact_demo.items')<>file_id AS different_file
FROM compact_demo.baseline;
SELECT count(*),min(id),max(id),sum(id),
 bool_and(payload=repeat(md5(id::text),10)) AS payloads_preserved
FROM compact_demo.items;
DO $$ BEGIN
 IF (SELECT sum(id) FROM compact_demo.items)<>2375250
 OR (SELECT count(*) FROM compact_demo.items)<>500
 OR EXISTS (SELECT FROM compact_demo.items
 WHERE payload<>repeat(md5(id::text),10)) THEN
 RAISE EXCEPTION 'compaction changed application data';
 END IF;
END $$;
DROP SCHEMA compact_demo CASCADE;

两个存储比较都返回真：堆文件更小，文件标识也变了。数据检查应返回五百行，编号范围四千五百零一至五千，编号总和为二百三十七万五千二百五十，所有载荷匹配也为真。断言同时检查记录数量与内容，因为文件变小本身并不能证明压缩过程保留了正确的数据。最后删除整个实验模式。

判断重写是否值得

如果后续插入本来就会使用现有空闲空间，保留这些容量可能比先付出重写代价、之后再次扩展文件更合适。应在负载趋于稳定后，评估持续存在的额外空间和访问成本。还要区分主堆文件、索引和辅助存储，因为一个笼统的表大小数字，可能混合了几类增长原因不同的对象。选择维护动作之前，先确认真正占空间的是哪一部分。

安排维护时，应确认业务可以接受独占锁，并在请求强锁之前检查长时间打开的读事务。流量低并不保证没有旧事务留下。取锁等待应有明确预算，失败后先观察原因，而不是无限重试；完成后同时验证数据和存储变化。日常仍要保持普通回收健康，避免严重积压变成每次都需要独占重写的维护循环。

这个实验在小表上展示了锁冲突、文件替换和行内容保留，却不能预测生产对象的重写耗时与额外容量。大索引、外部存储值和复制日志流量都会改变代价，需要结合实际对象测量。只有把可承受的锁窗口、磁盘余量和验证方式都纳入维护安排，文件压缩才是完整的操作，而不是一条碰运气的命令。

来源

PostgreSQL 18 VACUUM，重写、额外空间、尾部截断与事务限制，已核验 2026-09-10。
PostgreSQL 18 显式锁，强排他表锁与读取、写入的冲突关系，已核验 2026-09-10。
PostgreSQL 18 常规清理，日常空间复用与例外性的完整压缩，已核验 2026-09-10。

调优 · XB 现场笔记

部分索引的写入成本

区分成员资格与更新成本

可以使用与值得使用是两回事

坏掉的样子

快速验证

来源

延伸阅读

自动清理资格不等于执行完成

坏掉的样子

快速验证

找到真正限制清理的阶段

来源

查询变慢时同时检查计划与等待

保留可比较的基线

坏掉的样子

快速验证

顺着观察到的原因继续

来源

VACUUM FULL 重建一张表而不是修剪

坏掉的样子

快速验证

判断重写是否值得

来源