Postgres · XB 现场笔记

事务拿锁时别的请求会礼貌等待

Wed, 16 Feb 2028 00:00:00 +0000

等待锁可能是正常协调，也可能让连接和请求持续排队。PostgreSQL 的 lock_timeout 可以让调用方停止等待，但它不会解释持锁者为什么慢，更不会自动决定业务是否可以重试。应从操作能够接受的延迟出发设定预算，同时找到实际阻塞者；单纯延长超时或增加尝试次数，可能只是扩大同一条等待队列。

坏掉的样子

锁超时分别作用于每一次锁获取尝试，包括语句隐式申请的锁。它测量的是等待当前锁的时间，而不是整条语句的总运行时间。查询已经执行了一段时间，随后又申请一把锁，仍然可能触发这个限制。反过来，多次较短的等待也可能累计超过一个配置间隔。把锁超时理解成“只有语句刚开始时检查一次”，或把它当成整次查询的总截止时间，都会漏掉真实的等待范围。

statement_timeout 限制整条语句执行，其中也包括等锁。如果它更短，可能先于锁超时取消语句。空闲事务会话超时处理的则是另一种状态：事务还开着，但服务器正在等待客户端发下一条命令。卡在更新内部等待锁的后端通常仍是活动状态，等待事件属于锁；不能看到连接排队，就直接把所有等待者叫作空闲事务。真正闲着不提交的持锁者和正在等待的受阻者，需要分别定位。

快速验证

准备同一个 PostgreSQL 18 可丢弃数据库，开启甲、乙两个全新的 psql -X -v ON_ERROR_STOP=1 会话。实验使用默认的零值锁超时，且没有其他会提前干预的超时设置。下面的毫秒参数只用于快速复现，不是生产建议值。甲先建立独立模式和计数表：

CREATE SCHEMA timeout_demo;
CREATE TABLE timeout_demo.counter (id integer PRIMARY KEY,n integer);
INSERT INTO timeout_demo.counter VALUES (1,0);

甲在显式事务中把数字改成十，暂时不提交，也不回滚，以便继续持有目标行的锁：

BEGIN;
UPDATE timeout_demo.counter SET n=10 WHERE id=1;

乙开启事务，对同一行加一，并给取锁等待一百毫秒预算。为展示预期错误及后续事务状态，只在这一小段临时关闭遇错停止：

BEGIN;
SET LOCAL lock_timeout='100ms';
SET LOCAL statement_timeout='1s';
\set ON_ERROR_STOP off
UPDATE timeout_demo.counter SET n=n+1 WHERE id=1;
\echo lock_state :SQLSTATE
SELECT n FROM timeout_demo.counter WHERE id=1;
\echo transaction_state :SQLSTATE
\set ON_ERROR_STOP on
ROLLBACK;

先得到 55P03，随后查询得到 25P02。前者取消乙的更新，并使这个显式事务进入失败状态；后者说明原事务不能继续正常执行。乙的回滚只清理自己的失败事务，不会释放甲的锁，也不会取消甲尚未提交的十。若忽略回滚，直接在原事务里重发更新，只会继续收到事务状态错误。

甲仍保持事务打开。乙重新开始，这次把整条语句预算设成五十毫秒，比取锁的一百毫秒更短：

BEGIN;
SET LOCAL lock_timeout='100ms';
SET LOCAL statement_timeout='50ms';
\set ON_ERROR_STOP off
UPDATE timeout_demo.counter SET n=n+1 WHERE id=1;
\echo statement_state :SQLSTATE
\set ON_ERROR_STOP on
ROLLBACK;

此时得到 57014，说明语句取消先发生。等待的依然是同一行，改变的只是哪个计时器先到期。错误码需要结合上下文解释：不等待的取锁请求也可能返回 55P03，其他查询取消也可能返回 57014。单看这些类别，既不能认定已经检测到死锁，也不能直接知道阻塞者属于哪个应用操作。

甲现在回滚，丢弃尚未提交的十并释放行锁：

ROLLBACK;

乙开启一个新的有界事务，再次更新，这次返回一并成功提交：

BEGIN;
SET LOCAL lock_timeout='100ms';
SET LOCAL statement_timeout='1s';
UPDATE timeout_demo.counter SET n=n+1 WHERE id=1 RETURNING n;
COMMIT;

结果是一，因为乙先前的失败尝试都没有提交增量，甲的十也已回滚。乙继续验证普通执行时间与取锁等待时间的区别：

BEGIN;
SET LOCAL lock_timeout='50ms';
SET LOCAL statement_timeout='1s';
SELECT pg_sleep(0.2);
\echo sleep_state :SQLSTATE
COMMIT;
SHOW lock_timeout;

睡眠持续二百毫秒，超过锁等待预算五十毫秒，但正常返回成功状态。没有等待锁，不能仅凭耗时长就触发锁超时。提交之后，显示的锁超时恢复为会话原来的零，因为局部设置只持续到当前事务结束。最后由甲核对数据仍为一，并清理实验：

SELECT n FROM timeout_demo.counter WHERE id=1;
DROP SCHEMA timeout_demo CASCADE;

恢复时不要扩大竞争

是否重试应由具体操作决定。锁超时后先回滚，只有剩余请求预算足够、并且重放符合业务语义时，才开始新事务。少量尝试、随机退避和总截止时间可以限制额外负载，却不能让永久占用的资源凭空可用。耗尽预算时应保留最终错误和尝试次数，而不是静默丢弃请求，或把它报告成成功。

真正的死锁是依赖关系形成了环，数据库检测后会返回死锁错误。锁超时也可能抢在死锁检测之前到期，所以“这次只看见超时”不能证明没有循环等待。应结合阻塞进程、事务持续时间与取锁顺序检查原因。让持锁事务早点结束，特别是移走其中等待用户输入或外部服务的环节，往往比整体调大超时更有效。生产参数必须参考正常锁持有时间和业务延迟预算，不能照抄这个实验的毫秒数。

来源

PostgreSQL 18 客户端连接默认值，锁等待、语句与空闲事务超时的作用范围，已核验 2026-09-10。
PostgreSQL 18 显式锁，锁冲突及死锁检测，已核验 2026-09-10。

部分索引裁剪整列

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

并不是每一行都配得上一个索引槽位；部分索引让树尽量薄，正对查询从不关心的那些数据。多数表都有表结构假装看不见的偏斜：九成订单已关闭，几乎所有事件都已处理，标志列几乎处处为假。全量索引老老实实全记下来，每次写入都交维护费，保护的却是只碰一小片热数据的查询。部分索引不再为没人查的行付钱。

这笔交易拿精度换体积。索引更小、扫描更快、维护更便宜——但只有谓词与索引条件对得上的查询才能用它，其余统统回退到别的计划。所以部分索引是访问模式与存储的刻意配对，不是通用加速。只有热子集稳定、各查询对它的定义一致时才值得建。

只索引你要查的数据

部分索引带一个 WHERE 子句，不满足谓词的行根本不会进树。当大多数行很少被读时，树的体积因此更小，真正关心的那些行查找也更快。只给未关闭订单建的索引，可能比全量小一个数量级：更多内容装进缓存，每次查找碰更少的页，冷历史再怎么涨，计划依然走索引。

谓词从查询里挑，别从列统计里挑。正确的条件是每条重要查询本来就在重复的那一句：状态等于未关闭、删除时间为空。如果各查询切表的方式不同，一个部分索引伺候不了所有人——要么主导的那片胜出，要么建两个部分索引，每个都比全量瘦。定谓词之前，先让查询日志投票。

行更少、维护更省

条目越少，INSERT、UPDATE 还有 VACUUM 要碰的结构就越轻，磁盘占用也能肉眼可见地降下来。对写入频繁又大多是噪音的表，收益最明显。不满足谓词的插入整行跳过索引——没有页分裂风险，也不为它写日志；不改变谓词结果的更新同样跳过索引维护。对每秒吞噬几千冷写的表，省下的维护远超查询加速本身。

索引变小还会让清理更快：需要清理的页少了，膨胀无处藏身，表本来就要付的维护窗口跟着变短。上线后盯着它和全量等价物的体积比；部分索引一旦长到接近全量，说明谓词选出的早已不是少数，交易已经到期——删掉它，或重新定义切片。

部分索引还有一个容易漏掉的边界：规划阶段必须能证明查询条件蕴含索引谓词。把值写成预备语句参数，规划器无法对所有可能值提前证明，因此可能完全不用这个索引；不同写法的等价条件也未必能被识别。把热点条件固定成同一段查询构造，给带真实参数的 EXPLAIN 留一份回归样本，才能知道索引是在生产路径上工作，而不是只在建表演示里好看。

让语句与索引对得上

规划器通常只会为与部分索引谓词完全一致、或由其蕴含的查询选用它。所以查询里的过滤条件要照索引的写法写，规划器才能真正用得上。状态等于未关闭能命中条件相同的索引；状态属于两者之一则不行，哪怕人一眼能看出重叠。匹配器认的是逻辑蕴含，不是字面相似，而且设计上偏保守。

这份严格规定了一条纪律：全库统一热切片条件的写法。索引写的是删除时间为空，查询就不许写成删除时间等于空或包一层合并函数还指望走索引。把热条件收敛到一处——视图、作用域、查询构造器的片段——让每条语句继承逐字相同的谓词。执行计划是最终裁判：计划无视索引，说明两边谓词差在匹配器跨不过去的地方。

坏掉的样子

经典故障是谓词漂移：业务把"未关闭"重定义得多了一个状态，应用查询跟着改了，部分索引却悄悄对不上一半负载。不报错——计划一条一条退化成顺序扫描，延迟爬升，背锅的却找不到一次发布。上线时给核心查询加上计划断言，进持续集成或监控，断言计划里出现这个索引名。谓词漂移在发布当天就被抓住，而不是被发现的那个季度。

第二种故障是切太碎：一张表五个部分索引，各伺候一份报表，合计维护费超过当初要替换的全量索引。用索引统计视图审计：几乎零扫描的索引是删除候选，谓词重叠的是合并候选，合成一个更宽的部分索引。

快速验证

验证索引命中与体积收益：

CREATE INDEX ON orders (created_at) WHERE status = 'open';
EXPLAIN SELECT * FROM orders WHERE status = 'open' ORDER BY created_at LIMIT 20;
SELECT pg_size_pretty(pg_relation_size('orders_created_at_idx'));

计划必须走部分索引的索引扫描，体积应该是全量等价物的一小部分。

来源

PostgreSQL 部分索引，部分索引官方文档，已核验 2026-06-01。
PostgreSQL 执行计划，验证索引是否被选用的计划检查，已核验 2026-09-05。

分区裁剪跳过查询不可能用到的整张分区

Sun, 13 Feb 2028 00:00:00 +0000

分区裁剪排除的是整张不可能包含匹配行的分区。它与在剩余分区内部利用索引寻找行不同，也不是按页工作的缓存技巧。PostgreSQL 可以在查询规划阶段完成排除，也可以等参数值在执行过程中可用后再裁剪。要判断它是否生效，需要查看实际访问的分区，而不是只看最终返回了多少行。

证明哪些分区不可能命中

声明式分区的边界来自分区键。把日期键限制在十月，可以证明九月和十一月与查询无关。裁剪依赖这些边界，而不是估计其他分区“可能很少匹配”。统计信息仍影响其他规划决策，但行数估计不准，不会让分区归属变成概率判断；这两个层面的信息应分开解释。

裁剪不要求先建索引。排除无关分区后，如果剩余分区的大部分行都需要读取，PostgreSQL 完全可能选择顺序扫描。所以，出现 Index Scan 并不是裁剪成功的判据。应先检查物理关系名和计划结构，再单独评价剩余每张表内部的访问方式。顺序扫描一张相关分区，仍然可能已经省掉其他分区的大量工作。

条件必须能对应分区键及其比较语义。把日期列转换成文本，可能隐藏直接的边界关系，即使某个字符串条件恰好仍选出相同行。应使用有类型的参数和直接表达目标区间的条件，不能假定分区键外面套任意表达式都保留裁剪能力，甚至不能默认它保留原来的日期语义。

参数也能在执行时触发裁剪

常量可以支持规划期裁剪，使计划只留下相关子表。预备语句的通用计划无法提前知道未来每次传入的参数值，但这不表示它必须扫描全部分区：执行初始化时已经知道的值，也可以用于执行期裁剪。看见通用计划中原本存在多个分支，还不足以判断最终都会读取。

EXPLAIN ANALYZE 用 Subplans Removed 报告初始化阶段排除的分区。另一些情况，例如嵌套循环内侧参数在执行期间变化，可以在实际执行过程中继续裁剪。分析这些场景时，需要查看循环次数和子计划是否运行。某个节点显示从未执行，也可能是外层没有输入等其他原因，不能脱离完整计划单独当成裁剪证据。

因此，不能把这些规则简化成“只要不是常量表达式，就会失去裁剪”。参数何时可用，以及表达式是否受支持，共同决定何时能够排除分区。定制计划和通用计划可能不同，但返回同样答案。真正值得确认的是：负载使用真实参数时，哪些分区实际被访问了。

坏掉的样子

只过滤无关字段，可能让所有分区仍然相关；把键转换成无法对应边界的表达式，也可能产生同样结果。调整分区布局前，应检查准确条件和 enable_partition_pruning 设置。手工添加相互矛盾的 CHECK 约束并不是修复方法；普通本地声明式分区会执行自己的边界规则，而基于 CHECK 的约束排除是另一种优化机制。

裁剪也不保证没有锁或规划成本可以忽略。执行初始化阶段排除的分区，在执行开始时仍然会被锁定。大型分区层级可能消耗规划时间和会话内的元数据内存，即使最后只扫描少数子表。应根据真实查询和维护模式选择层级，而不是追求尽可能多的分区数量。

最后，即使裁掉两个分区，第三个分区内部仍可能有几千条无关行。合适的局部索引可能帮助第二阶段。最终返回一百行，不证明只检查了一百行；缓冲命中也不等于物理磁盘读取。必须沿着计划节点看清扫描、过滤与输出之间的区别。

快速验证

把下面内容保存为 partition-pruning.sql，在可丢弃的 PostgreSQL 18 数据库中执行 psql -X -v ON_ERROR_STOP=1 -f partition-pruning.sql。脚本在事务内启用裁剪，并用通用预备计划展示初始化阶段的行为。临时分区上没有建立任何索引。

\set ON_ERROR_STOP on
BEGIN;
SET LOCAL datestyle='ISO, YMD';
SET LOCAL enable_partition_pruning=on;
CREATE TEMP TABLE observations (day date,id integer) PARTITION BY RANGE(day);
CREATE TEMP TABLE obs_sep PARTITION OF observations FOR VALUES FROM ('2026-09-01') TO ('2026-10-01');
CREATE TEMP TABLE obs_oct PARTITION OF observations FOR VALUES FROM ('2026-10-01') TO ('2026-11-01');
CREATE TEMP TABLE obs_nov PARTITION OF observations FOR VALUES FROM ('2026-11-01') TO ('2026-12-01');
INSERT INTO observations SELECT DATE '2026-09-01'+g%90,g FROM generate_series(0,8999) AS g;
ANALYZE observations;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF)
SELECT count(*) FROM observations WHERE day>=DATE '2026-10-01' AND day<DATE '2026-11-01';
SET LOCAL plan_cache_mode=force_generic_plan;
PREPARE by_day(date) AS SELECT count(*) FROM observations WHERE day=$1;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF) EXECUTE by_day(DATE '2026-10-10');
EXECUTE by_day(DATE '2026-10-10');
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF)
SELECT count(*) FROM observations WHERE day::text='2026-10-10';
DO $$ BEGIN
 IF (SELECT count(*) FROM observations WHERE day=DATE '2026-10-10') <> 100 OR
 (SELECT count(*) FROM observations WHERE day>=DATE '2026-10-01' AND day<DATE '2026-11-01') <> 3100 THEN
 RAISE EXCEPTION 'unexpected pruned result';
 END IF;
END $$;
DEALLOCATE by_day;
ROLLBACK;

PostgreSQL 18.6 把常量十月区间规划为只扫描 obs_oct，读取三千一百条匹配行。通用日期查询报告 Subplans Removed 为二，返回一百行，但仍需在十月分区中过滤三千条其他记录。这同时展示了成功排除无关分区，以及相关分区内部尚未消除的工作量。

文本转换条件扫描三个子表，在明确指定 ISO DateStyle 后，仍返回相同的一百行。断言检查有类型查询的结果数量，DEALLOCATE 和回滚分别清理预备语句与临时表。这个结果验证当前示例中条件与裁剪的关系；选择索引或调整生产分区粒度前，还应测量有代表性的实际计划，不能直接把小实验的结构当成性能收益保证。

来源

PostgreSQL 表分区，规划期与执行期裁剪、边界及锁行为，已核验 2026-09-10。
PostgreSQL PREPARE，通用与定制计划及参数处理，已核验 2026-09-10。

表分区按范围或键拆分数据

Thu, 10 Feb 2028 00:00:00 +0000

范围分区把边界定义变成写入路由规则。PostgreSQL 按键值把行放到能够接受它的分区，无论这条数据准时到达，还是晚了几个月。任何查询获得裁剪收益之前，都需要先定义正确边界、使用匹配的时间类型，并安排缺失范围的处理流程。分区建表成功，只是这些条件中的一部分。

使用相邻的左闭右开范围

范围分区包含下界，不包含上界。九月可以从九月一日开始，一直到十月一日之前；十月正好从同一边界开始，双方不会重叠。不要靠猜测一个月最后可表示的时间戳来定义范围。相邻的左闭右开区间，不依赖时间字段究竟保留多少位小数，也能避免边界遗漏。

查询同样需要准确表达区间。大于等于下界、小于上界的条件，适合描述一个月的数据。BETWEEN 包含两个端点，因此，把下月第一瞬间写成其上界，可能把下个月的数据也查进来。分区路由只能执行数据布局规则，不能替一个请求了错误区间的条件修正业务含义。

分区键类型与时区也是定义的一部分。timestamptz 代表瞬间，不带时区的 timestamp 则代表没有对应时区解释的本地日期时间。示例为每个边界显式写出 UTC 偏移。如果业务月份按另一个时区划分，应根据那个时区的规则推导边界，而不是假定所有本地日期都对应相同的实际时长。

缺失范围是一种运维状态

没有分区接受新键值时，插入会报错，除非 DEFAULT 分区能够接住它。日历进入新月份，并不会让 PostgreSQL 自动创建下一张月表。应在写入需要之前创建范围，同时考虑迟到数据和旧日期修正。输入键不必单调增长，路由照样能够工作；关键是相应目标范围仍然存在。

DEFAULT 可以接收显式范围之外的值，减少立即发生的插入失败，但如果不检查默认表，也会掩盖分区管理遗漏。持续增长的默认分区可能混入多个互不相关的时间范围，让后续整理更困难。应让“有意保留的例外数据”与“忘记创建分区的日常数据”保持可辨认，不能把插入暂时不报错当成管理正常。

新增显式分区，会改变默认分区能够接受的值。如果新范围对应的行还留在 DEFAULT 中，PostgreSQL 会拒绝变更，而不会允许两处同时拥有这批数据。应先把这些行迁移到合适的暂存表或按规则处理，再挂载新分区。边界是被执行的数据规则，不是可以随意标错的说明标签。

坏掉的样子

下一月分区未创建时，部署可能恰好在跨月瞬间出现写入失败。补建分区又可能因为 DEFAULT 已经积累对应行而失败。这两种问题都属于路由和数据位置，不是规划器统计陈旧。应先检查被拒绝的键和当前边界，再决定操作，不能直接运行 ANALYZE 或改索引，希望它们修复缺失范围。

ATTACH 可能扫描候选表以验证边界，也可能检查默认分区中是否存在冲突数据。合适且已验证的约束能省去部分扫描，但操作仍需要锁，并要求表结构兼容。活跃表上迁移数据时，需要协调写入者和锁获取；一个隔离环境中的事务示例，不是完整的在线迁移操作方案。

是否允许空值，与范围选择是两回事。示例要求时间戳非空，避免缺失事件时间悄悄变成普通的例外数据。迁移后还应核对行数和标识；ATTACH 成功不能证明更早的复制步骤没有丢行或重复，数据核对不能省略。

快速验证

把下面内容保存为 partition-ranges.sql，在可丢弃的 PostgreSQL 18 数据库中执行 psql -X -v ON_ERROR_STOP=1 -f partition-ranges.sql。全部表都是临时表，整个实验最后回滚清除。

\set ON_ERROR_STOP on
BEGIN;
SET LOCAL timezone='UTC';
CREATE TEMP TABLE samples (at timestamptz NOT NULL,id integer) PARTITION BY RANGE(at);
CREATE TEMP TABLE samples_sep PARTITION OF samples
FOR VALUES FROM ('2026-09-01 00:00:00+00') TO ('2026-10-01 00:00:00+00');
INSERT INTO samples VALUES ('2026-09-01 00:00:00+00',1),('2026-09-30 23:59:59.999999+00',2);
DO $$ BEGIN
 INSERT INTO samples VALUES ('2026-10-01 00:00:00+00',3);
 RAISE EXCEPTION 'upper boundary entered September';
EXCEPTION WHEN check_violation THEN RAISE NOTICE 'upper boundary needs another partition';
END $$;
CREATE TEMP TABLE samples_default PARTITION OF samples DEFAULT;
INSERT INTO samples VALUES ('2026-10-01 00:00:00+00',3);
DO $$ BEGIN
 CREATE TEMP TABLE samples_oct_bad PARTITION OF samples
 FOR VALUES FROM ('2026-10-01 00:00:00+00') TO ('2026-11-01 00:00:00+00');
 RAISE EXCEPTION 'new partition overlapped populated default';
EXCEPTION WHEN check_violation THEN RAISE NOTICE 'matching default rows must be moved first';
END $$;
CREATE TEMP TABLE samples_oct (LIKE samples INCLUDING ALL);
WITH moved AS (
 DELETE FROM samples_default
 WHERE at >= TIMESTAMPTZ '2026-10-01 00:00:00+00' AND at < TIMESTAMPTZ '2026-11-01 00:00:00+00'
 RETURNING *
) INSERT INTO samples_oct SELECT * FROM moved;
ALTER TABLE samples ATTACH PARTITION samples_oct
FOR VALUES FROM ('2026-10-01 00:00:00+00') TO ('2026-11-01 00:00:00+00');
SELECT id,at,tableoid::regclass AS physical_table FROM samples ORDER BY id;
DO $$ BEGIN
 IF (SELECT array_agg(id ORDER BY id) FROM samples_sep) IS DISTINCT FROM ARRAY[1,2] OR
 (SELECT array_agg(id ORDER BY id) FROM samples_oct) IS DISTINCT FROM ARRAY[3] OR
 (SELECT count(*) FROM samples_default) <> 0 THEN
 RAISE EXCEPTION 'range migration lost or duplicated data';
 END IF;
END $$;
ROLLBACK;

PostgreSQL 18.6 接受了九月的第一瞬间，以及测试中十月开始前的最后一个微秒。没有相应目标时，十月一日被拒绝；创建 DEFAULT 后，这一行进入默认分区。随后尝试新增十月分区，因为匹配行仍留在 DEFAULT 中而失败，说明系统确实检查数据归属，并没有仅仅更新元信息。

脚本用 DELETE RETURNING 把该行移到暂存表，再把暂存表挂载为十月分区，并通过 tableoid 展示每条记录的实际物理表。标识一和二仍在九月，标识三位于十月，DEFAULT 为空。断言检查最终成员关系和行数，同时覆盖边界包含规则与完整迁移路径。这个结果不能被解释为未来范围管理可以省略，只说明测试中的布局已经正确完成。

来源

PostgreSQL 表分区，范围边界和路由行为，已核验 2026-09-10。
PostgreSQL ALTER TABLE，挂载验证、默认分区与锁，已核验 2026-09-10。

窗口函数在不合并组的前提下排名

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

排名函数为分区内的每一条输入行附加位置，不会把整个团队、部门或客户的数据压缩成一行聚合结果。真正需要选择的是并列的含义：每行占一个独立位置、允许并列且保留空位的竞赛名次，还是按不同分数组连续计数的名次。三种规则解决的问题不同，应先确定业务规则再写窗口。

三个问题对应三种排名

row_number() 从一开始给每行分配连续整数。如果两行的排序值完全相同，而窗口没有其他区分条件，它们的相对序号没有保证。需要恰好选出两位获胜者时，可以按分数降序，再按稳定且唯一的标识排序。这意味着同分时由标识决定谁占据剩余名额，不能把这个结果当成不影响业务的技术细节。

rank() 给同组并列行分配该组第一行的位置。分数为一百、九十、九十、八十时，名次依次为一、二、二、四。两位第二名占用了两个位置，因此下一档分数前面会留下空位。dense_rank() 则计算同分组的数量，对同一批数据给出一、二、二、三，不会因并列人数增加而跳号。

并列组由窗口 ORDER BY 中的全部表达式决定。如果把唯一标识也加入 rank 的窗口，即使本意只是稳定展示顺序，也会让原来的同分行不再并列。row_number 需要标识裁决、rank 需要保留同分时，应使用不同窗口定义。最终结果的展示顺序可以由外层 ORDER BY 控制，不必因此改掉排名所依据的并列关系。

明确分区与过滤时机

PARTITION BY 让每个组从头编号。不写分区条件时，窗口看到的所有输入行属于同一个分区。这和窗口帧是不同概念：排名依据分区顺序和并列组，不是对某段移动聚合帧计数。添加 ROWS 边界，不会把 rank 变成“这个边界内有多少行”的函数。

窗口看到的是 FROM、WHERE、分组和 HAVING 处理后剩余的行。因此，在同层查询中过滤，可能先删掉部分竞争者，再计算名次。如果需要先给所有人排名，再挑前几个位置，应在子查询或 CTE 中生成窗口值，然后到外层过滤。PostgreSQL 不允许直接把窗口函数放进 WHERE，这也提醒读者区分排名输入与排名输出。

“前两名”必须有明确含义。位置不大于二，每个分区最多返回两行；竞赛名次不大于二，会保留全部并列第二名，结果可能超过两行；密集名次不大于二，则选择前两个不同分数组。当第一档分数本身就有多人并列时，密集排名与竞赛排名的筛选结果也可能不同。这些是不同的结果集合，不是可以随意互换的性能写法。

坏掉的样子

row_number 缺少确定的并列裁决条件时，同分选手可能在重复查询中交换位置。反过来，在所有窗口都添加标识，又可能悄悄消除 rank 本来要保留的并列。测试时必须放入恰好卡在截止名次上的同分数据，不能只测每个分数都不同的情况。如果分数允许 NULL，还应明确空值顺序；PostgreSQL 降序默认把空值放前面，需要时应显式指定 NULLS LAST。

确定的排序也不能冻结持续变化的数据。新分数出现后，已有行可能在两次请求之间移动，所以偏移分页或保存的行号并不是持久身份。大规模排名可能需要排序和临时文件，多个不同的窗口顺序也可能增加处理步骤。应读取有代表性的执行计划，不能因为查询使用窗口函数，就假设一定只有一次廉价扫描。

快速验证

把下面内容保存为 ranking.sql，在可丢弃的 PostgreSQL 18 数据库中执行 psql -X -v ON_ERROR_STOP=1 -f ranking.sql。red 分区包含一次并列，blue 是独立分区；末尾回滚会清理临时表和临时视图。

\set ON_ERROR_STOP on
BEGIN;
CREATE TEMP TABLE scores (id integer, team text, score integer);
INSERT INTO scores VALUES (1,'red',100),(2,'red',90),(3,'red',90),(4,'red',80),(5,'blue',50);
CREATE TEMP VIEW ranked AS
SELECT *, row_number() OVER (PARTITION BY team ORDER BY score DESC,id) AS position,
 rank() OVER w AS rank_with_gaps, dense_rank() OVER w AS rank_without_gaps
FROM scores WINDOW w AS (PARTITION BY team ORDER BY score DESC);
SELECT * FROM ranked ORDER BY team,id;
SELECT count(*) AS top_two_positions FROM ranked WHERE team='red' AND position<=2;
SELECT count(*) AS top_two_ranks FROM ranked WHERE team='red' AND rank_with_gaps<=2;
DO $$ BEGIN
 IF (SELECT array_agg(rank_with_gaps ORDER BY id) FROM ranked WHERE team='red')
 IS DISTINCT FROM ARRAY[1,2,2,4]::bigint[] THEN RAISE EXCEPTION 'wrong rank'; END IF;
 IF (SELECT array_agg(rank_without_gaps ORDER BY id) FROM ranked WHERE team='red')
 IS DISTINCT FROM ARRAY[1,2,2,3]::bigint[] THEN RAISE EXCEPTION 'wrong dense rank'; END IF;
 IF (SELECT array_agg(id ORDER BY position) FROM ranked WHERE team='red' AND position<=2)
 IS DISTINCT FROM ARRAY[1,2] THEN RAISE EXCEPTION 'unstable top two'; END IF;
 IF (SELECT count(*) FROM ranked WHERE team='red' AND rank_with_gaps<=2) <> 3 THEN
 RAISE EXCEPTION 'tied second place was dropped';
 END IF;
END $$;
ROLLBACK;

PostgreSQL 18.6 实测中，red 的位置为一至四，竞赛名次为一、二、二、四，密集名次为一、二、二、三。blue 独立从一开始。按 red 的位置筛选前两行，会得到标识一和二；按竞赛名次不大于二筛选，则返回三行，保留两位第二名。这同时说明“每行还在”与“每个分区重新计数”的行为。

断言检查两个名次数组、预定的同分裁决结果和截止处的行数。把共享排名窗口改为包含 id，应该让这些预期失败，从而暴露展示稳定性与并列语义被混用的问题。这里的观察来自固定数据集；若报表需要在分数持续变化时仍保持稳定，还必须单独设计快照或分页规则，不能让临时排名承担它没有承诺的身份语义。

来源

PostgreSQL 窗口函数，排名函数与并列组，已核验 2026-09-10。
PostgreSQL 窗口教程，分区、排序和排名后的过滤，已核验 2026-09-10。

autovacuum 让高频写表保持轻装

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-09-10。
PostgreSQL 18 常规清理，触发公式及不同维护目的，已核验 2026-09-10。
PostgreSQL 18 累计统计，手动和自动计数及统计缓存，已核验 2026-09-10。
PostgreSQL 18 统计函数实现，实验用于同步观察的刷新辅助函数，已核验 2026-09-10。

代理键把身份与含义分开

Wed, 02 Feb 2028 00:00:00 +0000

代理主键把一行记录的身份与可能变化的业务值分开。客户修改邮箱时，订单仍引用同一个客户编号，而不必跟着邮箱一起改引用。这对于易变或较宽的业务键很有用，但稳定性来自数据库约束与应用规则，不是“自动生成”四个字本身。一个生成的数字不会天然不可修改、保密、全局唯一，也不能代替访问授权。

生成身份与约束唯一性

PostgreSQL identity 列从关联序列取得默认值。GENERATED ALWAYS AS IDENTITY 会拒绝普通显式赋值，GENERATED BY DEFAULT 则允许调用方提供值。即使使用 ALWAYS，导入时仍可通过 OVERRIDING SYSTEM VALUE 显式覆盖。两种形式都不会单独保证值唯一；需要拒绝重复标识时，仍须声明 PRIMARY KEY 或 UNIQUE 约束。

主键同时保证唯一与非空，并提供可供引用使用的索引。Identity 负责怎样生成默认值，约束负责哪些最终值允许存储，这两项职责不能混淆。导入时尤其如此：显式写入一个很大的编号，不会自动把序列推进到那个位置。若没有协调序列状态，后续生成值可能最终与导入行相撞，直到主键报错才暴露问题。

单独保留业务唯一规则

代理编号不会阻止相同业务实体重复出现。如果邮箱是唯一登录标识，应继续保留明确的唯一约束，并先决定规范化规则。普通 text 的 UNIQUE 使用该列的比较语义，不会暗中替应用处理大小写折叠、空白或各种邮箱等价规则。迁移之前就要明确这些行为，否则数据库认为不同的值，应用可能认为是同一账号，或者反过来。

子表如果不能出现悬空引用，就需要真实的外键约束。邮箱不是引用键时，修改它不会改变订单指向的客户，因为订单保存的是 id。这缩小了这一项修改的范围，却不能承诺所有业务改名都变成简单操作：搜索索引、审计记录、外部集成和缓存仍可能依赖邮箱，需要按实际调用链更新。数据模型只解决它真正覆盖的关系。

坏掉的样子

把序列编号当成创建顺序或提交顺序，在并发下会产生错误结果。多个事务可能先后取号却反向提交，失败语句也可能留下空洞。展示排序应使用明确的时间字段并补充稳定决胜字段，不能根据编号连续性推断是否丢单。顺序编号也容易被猜到；即使另加不透明的公开标识，授权仍必须检查请求者与资源之间的关系，不能靠“不容易猜”保护数据。

导入时覆盖 identity 是另一种陷阱。插入的显式编号远大于序列当前位置，序列仍可能继续从较小值生成，最终碰到已有主键。应在受控导入流程中协调序列状态，并排除或正确协调并发写入。另开一个会话查询 max(id) 再加一，不是并发安全的分配算法；两个调用方可能同时得到相同结果。

迁移还可能意外删掉原自然键承担的唯一规则。换键之前要检查重复值与 null，保留真正需要的业务唯一约束，并沿所有真实引用更新。也不必仅因代理键常见就给每张表增加一列和一个索引；稳定自然键如果已经准确表达契约，也可能是合适选择。决策依据应是业务值的可变性、引用范围和数据语义。

快速验证

把下面代码保存为 identity.sql，运行 psql -X -v ON_ERROR_STOP=1 -f identity.sql，连接一个可丢弃的 PostgreSQL 18 数据库。实验使用临时表并在末尾回滚，不依赖已有 users 表，也不需要读取真实用户邮箱。所有地址都采用保留的 example.test 域名，仅用于构造可重复的数据。

\set ON_ERROR_STOP on
BEGIN;
CREATE TEMP TABLE users (
 id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
 email text NOT NULL UNIQUE
);
CREATE TEMP TABLE orders (
 id integer PRIMARY KEY,
 user_id bigint NOT NULL REFERENCES users(id)
);
INSERT INTO users(email) VALUES ('a@example.test') RETURNING id AS owner_id \gset
INSERT INTO orders VALUES (1, :owner_id);
UPDATE users SET email='renamed@example.test' WHERE id=:owner_id;
SELECT u.id, u.email FROM orders o JOIN users u ON u.id=o.user_id;
DO $$ BEGIN
 INSERT INTO users(email) VALUES ('renamed@example.test');
 RAISE EXCEPTION 'duplicate email accepted';
EXCEPTION WHEN unique_violation THEN RAISE NOTICE 'duplicate email rejected';
END $$;
DO $$ BEGIN
 INSERT INTO users(id,email) VALUES (99,'manual@example.test');
 RAISE EXCEPTION 'explicit identity accepted without override';
EXCEPTION WHEN generated_always THEN RAISE NOTICE 'explicit identity rejected';
END $$;
INSERT INTO users(id,email) OVERRIDING SYSTEM VALUE VALUES (100,'import@example.test');
INSERT INTO users(email) VALUES ('next@example.test') RETURNING id;
DO $$ BEGIN
 IF (SELECT email FROM users u JOIN orders o ON u.id=o.user_id)
 IS DISTINCT FROM 'renamed@example.test' THEN
 RAISE EXCEPTION 'rename broke the reference';
 END IF;
 IF (SELECT id FROM users WHERE email='next@example.test') IS DISTINCT FROM 3 THEN
 RAISE EXCEPTION 'unexpected identity sequence position';
 END IF;
END $$;
ROLLBACK;

邮箱修改后，订单仍然关联到编号一的客户。重复邮箱被唯一约束拒绝，而这次失败插入已经消耗了序列值二。没有覆盖子句的显式 identity 插入被拒绝；受控覆盖随后写入编号一百，但下一条正常生成记录拿到的是三，说明显式导入没有重定位序列。代码同时断言引用仍然正确，以及这个隔离夹具中的具体序列结果。

这些行为已在 PostgreSQL 18.6 验证。最后回滚清理实验对象，不能据此宣称普通业务事务中的序列不会有空洞。这个练习把生成机制、主键约束、外键完整性、业务唯一性与访问控制分开说明，避免把所有涉及 id 的规则都误认为由 identity 列自动完成。真正迁移时还要验证既有数据与并发写入流程，而不是只复制建表语句。

来源

PostgreSQL identity 列，生成模式与唯一性限制，已核验 2026-09-10。
PostgreSQL 约束，主键与引用完整性，已核验 2026-09-10。
PostgreSQL 序列函数，不随事务回滚的分配与空洞，已核验 2026-09-10。

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

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

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

保留可比较的基线

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

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

坏掉的样子

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

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

快速验证

打开三个新的 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-09-10。
PostgreSQL 18：使用 EXPLAIN，行数、循环次数与计划解读，已核验 2026-09-10。

PostgreSQL 使用两层数据缓存

Thu, 27 Jan 2028 00:00:00 +0000

普通缓冲式关系文件读写中，PostgreSQL 的共享缓冲位于操作系统文件缓存之上。命中共享缓冲时，不需要再次通过下面的文件读取路径；没有命中时，也可能由操作系统直接从内存提供数据。同一文件内容可以在两层各有副本，所以这里并不承诺数据库与内核共用同一份物理内存，更不能把两层缓存理解为完全没有重复占用。

坏掉的样子

执行计划里的共享读取计数，表示块被读入 PostgreSQL 缓冲池，不证明存储设备实际执行了一次物理读取。如果把每次共享读取都算成磁盘未命中，已经温热的操作系统缓存也会被误认为冰冷，从而引出错误的内存配置判断。同样，第二次查询更快，也不能独自说明究竟是哪一层缓存发生了变化，或是否只是其他执行条件改变。

缓存驻留是临时状态。其他查询可能挤走页面，工作集超过容量时，也不能指望所有页永久留在内存里；关系扫描采用的缓冲策略还可能影响复用方式。因此应使用已知大小的工作集、检查实际访问路径，并把耗时结论与真正观察到的缓存层事实分开。没有设备层测量，就不能仅凭一个计划字段宣布磁盘速度发生了变化。

快速验证

使用 PostgreSQL 18 可丢弃实例和超级用户，确保附带的缓冲观察与预热扩展可安装、且尚未安装。本次实例使用一百二十八兆字节共享缓冲，下面的数据可以轻松放下。通过一个全新的 psql -X -v ON_ERROR_STOP=1 会话按顺序执行。关系驱逐函数用于开发测试，这里只针对隔离实验创建的对象操作：

CREATE SCHEMA cache_layer_demo;
CREATE EXTENSION pg_buffercache WITH SCHEMA cache_layer_demo;
CREATE EXTENSION pg_prewarm WITH SCHEMA cache_layer_demo;
CREATE TABLE cache_layer_demo.items (id integer PRIMARY KEY,payload text)
 WITH (autovacuum_enabled=false);
INSERT INTO cache_layer_demo.items
SELECT g,repeat(md5(g::text),10) FROM generate_series(1,12000) AS g;
VACUUM (ANALYZE) cache_layer_demo.items;
CREATE VIEW cache_layer_demo.residency AS
SELECT count(*) AS heap_buffers FROM cache_layer_demo.pg_buffercache
WHERE reldatabase=(SELECT oid FROM pg_database WHERE datname=current_database())
 AND relfilenode=pg_relation_filenode('cache_layer_demo.items')
 AND relforknumber=0;
SET max_parallel_workers_per_gather=0;
SELECT pg_relation_size('cache_layer_demo.items')/current_setting('block_size')::int AS heap_blocks;
SELECT heap_buffers>0 AS initially_buffered FROM cache_layer_demo.residency;

本次构建的主堆有五百四十六个块，初始缓存比较返回真。观察视图同时限制数据库、当前文件标识与主分支，避免把其他关系或辅助分支的缓冲算进来。接着，仅驱逐这个关系的共享缓冲：

SELECT * FROM cache_layer_demo.pg_buffercache_evict_relation('cache_layer_demo.items'::regclass);
SELECT heap_buffers=0 AS no_shared_heap_buffers FROM cache_layer_demo.residency;

函数返回驱逐、刷出和未能驱逐的数量，本次分别为五百五十、五百五十和零。总数包含辅助分支，所以比只统计主堆的块数更大。后面的比较确认主堆共享缓冲已为空，但这个结果没有回答操作系统里是否仍然缓存着同一批文件页面。两层的状态需要分别观察，不能从一层为空推断另一层也为空。

通过操作系统同步读取主堆，但不把内容加载进数据库共享缓冲：

SELECT cache_layer_demo.pg_prewarm('cache_layer_demo.items','read','main');
SELECT heap_buffers=0 AS still_no_shared_heap_buffers FROM cache_layer_demo.residency;

预热函数处理了五百四十六个块，共享缓冲数量仍是零。这里选择的是同步读取模式；若改用缓冲模式，就会把页加载到数据库缓冲池。现在执行一个需要访问全部载荷的查询：

EXPLAIN (ANALYZE,BUFFERS,COSTS OFF,TIMING OFF,SUMMARY OFF,FORMAT JSON)
SELECT sum(length(payload)) FROM cache_layer_demo.items;

顺序扫描报告五百四十六次共享读取，共享命中为零。这与操作系统缓存已经温热完全相容，不能把它翻译成五百四十六次设备读操作。再执行同样的查询：

EXPLAIN (ANALYZE,BUFFERS,COSTS OFF,TIMING OFF,SUMMARY OFF,FORMAT JSON)
SELECT sum(length(payload)) FROM cache_layer_demo.items;

第二次扫描共享读取为零，共享命中为五百四十六。两次都处理一万两千行，所以缓冲计数变化并不是因为查询少读了业务记录。最后核对驻留状态和聚合结果，再清理实验与扩展：

SELECT heap_buffers>0 AS now_shared FROM cache_layer_demo.residency;
SELECT sum(length(payload)) FROM cache_layer_demo.items;
RESET max_parallel_workers_per_gather;
DROP SCHEMA cache_layer_demo CASCADE;

载荷字符总数应为三百八十四万，共享驻留比较为真。精确块数取决于行布局和构建参数；关键观察是同步预热后共享缓冲仍为空，首次查询发生共享读取，再次查询转为命中。这些结果没有测量设备延迟，也不保证某个固定倍数的加速。用它们说明缓存层次是合适的，用来预测生产查询耗时则证据不足。

为整个服务器分配内存

资源配置文档对内存充足的专用服务器，给出了共享缓冲约占系统内存四分之一的起始建议，但这不是任何负载都最优的常数。连接本身、并发排序与哈希、维护任务，以及操作系统缓存，都在使用同一个主机预算。只增加一层的容量，可能把其他工作所需的余量挤掉，因此不能孤立地看共享命中率决定配置。

修改之前应测量有代表性的工作集与并发请求。全部缓存已经温热的微型测试会隐藏读写压力，完全冷启动测试又可能夸大平时高度复用页面的负载代价。把缓存层计数、设备层观察和查询结果结合起来，才能把配置调整的收益归到它实际改变的那一部分，而不是把所有内存读取都叫作磁盘优化。

来源

PostgreSQL 18 资源消耗，共享缓冲与操作系统缓存的内存预算，已核验 2026-09-10。
PostgreSQL 18 pg_prewarm，同步读取和数据库缓冲预热模式，已核验 2026-09-10。
PostgreSQL 18 pg_buffercache，缓冲身份及开发测试用的关系驱逐函数，已核验 2026-09-10。

哈希索引复核碰撞，也要维护变化的键

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

PostgreSQL 哈希索引先利用哈希码缩小等值查询的候选范围，再回到表中核对原始值。哈希匹配只说明“可能相等”，不能直接证明相等。两个不同值可能具有相同哈希码，不同哈希码也可能映射到同一个桶。正常复核存在时，碰撞和共享桶都不意味着查询会返回错误结果；它们是实现需要处理的普通情况，而不是可以忽略的例外。

桶里究竟保存什么

索引条目包含四字节哈希值和指向表元组的引用，不保存完整的被索引列值。桶映射把查询导向相关索引页面。桶是共享存储空间，并不是给每个不同键单独分配一个专属位置。一个桶的主页装满后，可以继续连接溢出页，查询这个桶时也需要访问这些页面。因此，“一次算出桶”不等于“永远只读取一个页面”。

PostgreSQL 可以在单个索引页内部按哈希码排序，以便加速局部搜索，但这不会提供原始列值的顺序。哈希索引不能满足键范围或有序输出，只支持单列等值访问，不能强制唯一性，也不支持 IS NULL。B-tree 仍然可以服务等值查询，同时支持更广的一组操作，不能因为键看起来适合哈希就自动排除其他候选。

由于条目中没有原始值，哈希扫描是有损候选扫描，需要用表中实际值复核。因此，碰撞可以在执行计划中表现为 Rows Removed by Index Recheck。这说明数据库正确剔除了只在哈希上匹配的候选，而不是把两个碰撞值都当成相等返回。解读这项指标时，应把候选数量与最终答案区分开。

坏掉的样子

把索引键更新描述为“只碰一个桶”，掩盖了实际工作。修改被索引列会改变元组对应的索引值，新条目可能进入另一个桶。PostgreSQL 使用行版本与延后索引清理，旧引用不一定立刻从结构中消失。数据增长还可能触发桶分裂，溢出页也会增加读写。因此不能用一个理想化的哈希表赋值过程来解释数据库的全部更新成本。

高度重复的值、快速增长的表，与近乎唯一而稳定的等值负载，表现可能很不一样。哈希查询不是无条件的恒定延迟承诺。现代 PostgreSQL 的哈希索引支持崩溃恢复，但持久性既不会消除维护成本，也不会让它突然具备唯一性约束能力。读性能、写维护和数据契约必须分别确认。

快速验证

在可丢弃的 PostgreSQL 18 数据库中，用 psql 执行下面代码。它建立二十万个采用 C 排序规则的临时文本键，使用当前服务器自己的 hashtext 找到一组碰撞，再验证等值查询和键更新。实验没有把哈希码当成跨版本稳定的业务标识，最后回滚会移除所有夹具。

\set ON_ERROR_STOP on
BEGIN;
CREATE TEMP TABLE hash_items (key text COLLATE "C");
INSERT INTO hash_items SELECT 'key-'||g FROM generate_series(1,200000) AS g;
CREATE TEMP TABLE collision_pair AS
SELECT min(key) AS a,max(key) AS b FROM hash_items
GROUP BY hashtext(key) HAVING count(*)>1 ORDER BY hashtext(key) LIMIT 1;
SELECT a AS collision_a,b AS collision_b FROM collision_pair \gset
SELECT a,b,hashtext(a),hashtext(b) FROM collision_pair;
CREATE INDEX hash_items_key ON hash_items USING hash(key);
ANALYZE hash_items;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF) SELECT key FROM hash_items WHERE key=:'collision_a';
UPDATE hash_items SET key='changed-'||key WHERE key=:'collision_a';
SELECT count(*) AS old_key_rows FROM hash_items WHERE key=:'collision_a';
SELECT count(*) AS new_key_rows FROM hash_items WHERE key='changed-'||:'collision_a';
DO $$ BEGIN
 IF (SELECT hashtext(a)=hashtext(b) AND a<>b FROM collision_pair) IS DISTINCT FROM true THEN
 RAISE EXCEPTION 'fixture did not establish a collision';
 END IF;
 IF (SELECT count(*) FROM hash_items h JOIN collision_pair p ON h.key=p.a) <> 0 OR
 (SELECT count(*) FROM hash_items h JOIN collision_pair p ON h.key='changed-'||p.a) <> 1 OR
 (SELECT count(*) FROM hash_items h JOIN collision_pair p ON h.key=p.b) <> 1 THEN
 RAISE EXCEPTION 'hash lookup or indexed update returned wrong keys';
 END IF;
END $$;
ROLLBACK;

PostgreSQL 18.6 中找到的两个键是 key-129539 与 key-7295，哈希码都是 -1960436116。等值计划使用 hash_items_key，最终只返回一行，同时报告一行被索引复核移除。两段字符串虽然哈希相同，却仍然是不同的值。这是反对“哈希码没有碰撞”这一错误假设的实际负向验证，不能用普通的无碰撞点查替代。

将第一个键改成带 changed- 前缀的新值后，旧值查到零行，新值查到一行，另一条碰撞记录仍然查到一行。最终断言分别验证这三件事，并确认原始两个值确实具有相同哈希而内容不同。仅仅看到更新命令成功，还不足以证明同桶或同哈希的其他记录没有受到错误影响。

具体碰撞键和计划形状来自这一版本的实测。如果其他环境没有找到碰撞对，脚本应停止，不能宣称已经验证碰撞复核。即使换个环境找到另一组键，语义要求仍然不变：精确相等只能返回原始值符合条件的记录；修改一个值，不得因为另一个值哈希相同而改变它。固定的结果契约比固定某个内部哈希码更重要。

把维护也放进性能评估

使用有代表性的分布一起测量页面访问、等值延迟、更新行为和索引大小。VACUUM 可以移除失效引用、回收溢出页供结构内部复用，但不会缩小哈希索引的桶数量，也不会把这部分分配直接归还操作系统。重建属于另外的维护操作，本身需要成本。较小的哈希条目确实可能有价值，但只有完整负载比较才能判断它是否抵得过复核、溢出页和写维护开销。

来源

PostgreSQL 18：哈希索引，碰撞复核与桶维护，已核验 2026-09-10。
PostgreSQL 18：索引类型，B-tree 与哈希索引支持的条件，已核验 2026-09-10。

LATERAL 让每一行都有自己的子查询窗口

Wed, 19 Jan 2028 00:00:00 +0000

LATERAL 允许 FROM 中的一个项目引用它前面项目提供的列。每个父记录需要一个带自身参数的小结果集时，它很实用，例如每位客户最近的两笔订单。整个查询仍是一条 SQL、一次数据库往返，横向子查询明确表达哪些外层值决定当前结果。但这种逻辑关系不承诺唯一的物理执行策略，规划器仍可进行保持语义的优化。

把关联条件写清楚

普通 FROM 子查询不能随意引用旁边表的列，LATERAL 允许在合适的连接位置使用这些引用。o.customer_id = c.id 才是当前客户与订单之间的关联；只写关键词不会自动产生这个条件。如果删除关联，每位客户可能都拿到同一份全局结果。语法通过只能证明语句合法，不能证明取到的是这个客户自己的订单。

实现每组前几名时，把父记录过滤条件、ORDER BY 和 LIMIT 都放进横向子查询。放在整个连接外面的 LIMIT 限制的是最终组合结果，不是每位客户最多几笔订单。排序还需要唯一的决胜字段：两笔订单完全可能具有相同时间戳，只按时间排序时，边界位置选择哪一行没有保证，换一个计划就可能换一个答案。

子查询里的 ORDER BY 决定入选哪些行，并不保证最终结果的展示顺序。客户端要求稳定的客户与订单顺序时，还需要外层 ORDER BY。导出报表和自动化检查尤其依赖这一点；不能因为当前执行计划碰巧按某个顺序返回，就把这种偶然表现当成接口契约，否则升级或统计信息刷新后会出现难以解释的行顺序变化。

决定没有匹配时保留什么

CROSS JOIN LATERAL 在子查询没有返回行时会丢掉对应父记录。LEFT JOIN LATERAL 配合 ON true 则保留父记录，并把右侧列补成 null。对尚未下单的客户，后者往往才符合页面或报表需求。如果把右侧条件移到外层 WHERE，补出来的 null 行可能被过滤掉，原本想保留空客户的行为就被破坏了。

聚合还有一层区别。COUNT(r.id) 只统计非空订单标识，COUNT(*) 连左连接补出的那一行也会计算。没有 GROUP BY 的相关聚合，即使输入为空也可能返回一行，COUNT 是零，SUM 则是 null。因此不能把所有 LATERAL 表达式都理解成同一种列表查询，必须看它实际返回零行、一行还是多行，以及每一列的空值含义。

坏掉的样子

一种危险的“修复”是为了消除外层引用的语法错误，直接删除关联条件。查询之后正常运行，但每位客户都获得全站最近的订单，汇总数字被放大仍可能看起来合理。测试应覆盖没有订单、只有一笔、有多笔以及时间相同的客户。断言确切订单标识比只验证查询成功更有价值，因为它能发现归属错误与排序边界错误。

另一种问题是昂贵的内层操作随着外层行数反复执行。以关联键开头、后接所需排序字段的索引，可以支持选择性较高的 top-N 查找，但不保证一定被选择，小表尤其如此。查看 EXPLAIN 的 actual loops 和行数，外层涉及大量客户时还应比较窗口函数方案。LATERAL 消除的是客户端逐个查询的往返，不会让数据库内部的工作量凭空消失。

快速验证

将下面代码保存为 lateral.sql，使用 psql -X -v ON_ERROR_STOP=1 -f lateral.sql 连接一个可丢弃的 PostgreSQL 18 数据库。实验在一个事务中创建三位客户、四笔订单、匹配的索引和临时视图，所有数据都在代码中给出，不依赖已有业务表，也不需要猜测字段含义。

\set ON_ERROR_STOP on
BEGIN;
SET LOCAL statement_timeout = '5s';
CREATE TEMP TABLE customers (id integer PRIMARY KEY, name text);
CREATE TEMP TABLE orders (id integer PRIMARY KEY, customer_id integer, placed_at date);
INSERT INTO customers VALUES (1,'Ada'), (2,'Lin'), (3,'Sam');
INSERT INTO orders VALUES
 (10,1,'2026-09-01'), (11,1,'2026-09-02'), (12,1,'2026-09-02'),
 (20,2,'2026-09-01');
CREATE INDEX orders_recent ON orders (customer_id, placed_at DESC, id DESC);
ANALYZE customers;
ANALYZE orders;
CREATE TEMP VIEW recent AS
SELECT c.id AS customer_id, r.id AS order_id
FROM customers c LEFT JOIN LATERAL (
 SELECT o.id FROM orders o WHERE o.customer_id=c.id
 ORDER BY o.placed_at DESC, o.id DESC LIMIT 2
) r ON true;
SELECT * FROM recent ORDER BY customer_id, order_id DESC;
SELECT c.id, count(r.id) AS selected_orders
FROM customers c LEFT JOIN LATERAL (
 SELECT o.id FROM orders o WHERE o.customer_id=c.id
 ORDER BY o.placed_at DESC, o.id DESC LIMIT 2
) r ON true GROUP BY c.id ORDER BY c.id;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF) SELECT * FROM recent;
DO $$ BEGIN
 IF (SELECT array_agg(order_id ORDER BY order_id) FROM recent WHERE customer_id=1)
 IS DISTINCT FROM ARRAY[11,12] THEN
 RAISE EXCEPTION 'top two or tie-breaker is wrong';
 END IF;
 IF NOT EXISTS (SELECT FROM recent WHERE customer_id=3 AND order_id IS NULL) THEN
 RAISE EXCEPTION 'LEFT JOIN lost the customer without orders';
 END IF;
 IF (SELECT count(*) FROM recent) <> 4 THEN RAISE EXCEPTION 'wrong row count'; END IF;
END $$;
ROLLBACK;

结果依次包含 (1,12)、(1,11)、(2,20)，以及第三位客户配一个 null 订单。匹配订单数量分别是二、一、零。十一和十二号订单的日期相同，用来检查标识字段是否稳定决定先后；第三位客户则验证没有匹配时是否仍然保留。断言检查具体标识和总行数，最后的回滚移除全部临时对象。

PostgreSQL 18.6 在这份四笔订单的夹具上使用了重复的小表扫描，这很合理，不能据此断定设计中的索引在大数据量下无效。反过来，也不能因为建了索引就要求任何计划都显示索引扫描。性能结论需要接近真实的客户数量和订单分布，正确性结论则来自关联条件、连接类型与确定排序。五秒 statement timeout 为实验单条语句设定执行上限，并不代替生产负载评估。

来源

PostgreSQL 表表达式，横向引用与外连接语义，已核验 2026-09-10。
PostgreSQL SELECT，排序与 LIMIT 行为，已核验 2026-09-10。

pg_dump 拍一张一致的快照

Fri, 14 Jan 2028 00:00:00 +0000

pg_dump 使用事务数据的一致视图导出一个 PostgreSQL 数据库，同时允许其他会话继续提交变化。它避免了普通逐表复制的问题：前一张表和后一张表不会因为读取时间不同，就混入彼此不一致的已提交状态。但快照只是备份契约的一部分；归档还必须覆盖需要的数据范围，能被兼容工具读取，并且实际恢复成可使用的数据库。

理解快照覆盖什么

导出期间，快照可见的行构成稳定视图。后续提交不会因为某张表读得晚，就逐渐混进同一次导出。并行导出让各 worker 使用同步快照，而不是各自随时读取。并行 dump 要求 directory 格式；custom 格式支持并行恢复，但不支持并行导出。格式选择应根据导出与恢复两边的需求分别判断，不能把两个方向混为一谈。

数据库快照不会自动让整个业务流程原子化。如果应用分两个事务提交批次头和明细，一致快照完全可能合法地落在这两次提交之间。序列状态也不是普通的 MVCC 行数据，外部文件和其他服务更不在数据库快照范围内。恢复需要满足什么业务不变量，必须结合真实事务边界和所需数据源定义，不能只凭“同一快照”推断所有业务状态都完整。

计算负载和依赖

普通读取和写入通常可以在导出期间继续，但 pg_dump 仍获取 ACCESS SHARE 锁，也消耗 CPU、I/O、连接和快照存活时间。冲突的 DDL 可能等待，也可能使导出失败；长快照会阻止某些旧行版本被清理。增加并行 worker 只是用更多并发资源换时间，不会让备份开销消失。应记录事务年龄和线上负载，避免把备份的影响误认为无关故障。

使用备库可以分担读取，但要考虑恢复冲突与复制延迟，而且从备库导出会排除非日志表内容。一次 pg_dump 也不包含集群级角色和表空间。扩展、所有者、权限、排序规则行为及目标配置，都需要通过合适机制纳入恢复计划。把整个库拆成互不协调的单表 dump，可能丢失共同快照，也可能遗漏这些表依赖的对象，不能当成免费的优化。

坏掉的样子

归档目录能够列出，不代表恢复一定成功。目标缺少角色或扩展时，表数据可能只恢复了一部分。应把归档加载到隔离空库，明确处理错误，再验证业务不变量和代表性查询。pg_restore 默认遇到 SQL 错误仍会继续，最后汇总错误数量；只看到最后一条查询有输出是不够的。小型演练可使用单事务恢复获得原子性，但这个模式不能与并行 job 同用。

工具版本是另一条边界。pg_dump 客户端会拒绝比自身主版本更新的服务器，输出主要面向相同或更新的目标版本，不能保证可以加载到更旧的主版本。应核对客户端、源库、目标库、扩展和恢复选项的实际组合，而不是只说“都是 PostgreSQL 所以可以恢复”。即使语法兼容，排序规则或权限差异也可能改变应用行为。

逻辑导出可以满足经测量确认的恢复目标，但不能任意重放到两次导出之间的时刻。物理基础备份加完整保留的 WAL 链，才提供对应的时间点恢复路径。导出间隔是否可接受，取决于允许的数据丢失窗口和恢复时间，不存在“短于一天就一定不行”的统一阈值。必须按实际要求设计留存与恢复链条。

快速验证

把 Bash 代码保存为 dump.sh。它自行创建实验 PostgreSQL 集群，并在退出时删除。可以用非 root 用户运行 PostgreSQL 18 工具，也可以使用下面的隔离容器；命令不发布网络端口，不挂载宿主机数据。两个数据库、归档和成功标记都只存在于实验临时目录及集群中。

docker run --rm --network none --user postgres --entrypoint bash -i \
 postgres:18-alpine < dump.sh

#!/usr/bin/env bash
set -euo pipefail
dump_lab=$(mktemp -d /tmp/pgdump-lab.XXXXXX)
cleanup() {
 if [ -f "$dump_lab/data/postmaster.pid" ]; then
 pg_ctl -D "$dump_lab/data" -m fast -w stop >/dev/null
 fi
 rm -rf -- "$dump_lab"
}
trap cleanup EXIT
initdb -D "$dump_lab/data" --no-locale --encoding=UTF8 --auth=trust >/dev/null
pg_ctl -D "$dump_lab/data" -l "$dump_lab/server.log" \
 -o "-k $dump_lab -p 55432 -c listen_addresses=''" -w start >/dev/null
export PGHOST="$dump_lab" PGPORT=55432 PGDATABASE=source_db
export DUMP_FILE="$dump_lab/source.dump" DUMP_OK="$dump_lab/dump-ok"
createdb source_db
createdb restored_db
psql -X -v ON_ERROR_STOP=1 <<'SQL'
CREATE TABLE customers (id integer PRIMARY KEY, name text);
CREATE TABLE orders (id integer PRIMARY KEY, customer_id integer REFERENCES customers(id));
INSERT INTO customers VALUES (1,'before');
INSERT INTO orders VALUES (10,1);
BEGIN ISOLATION LEVEL REPEATABLE READ READ ONLY;
SELECT pg_export_snapshot() AS snapshot_id \gset
\setenv DUMP_SNAPSHOT :snapshot_id
\! psql -X -v ON_ERROR_STOP=1 -c "BEGIN; INSERT INTO customers VALUES (2,'after'); INSERT INTO orders VALUES (20,2); COMMIT;" && pg_dump --format=custom --snapshot="$DUMP_SNAPSHOT" --file="$DUMP_FILE" && touch "$DUMP_OK"
COMMIT;
SQL
test -f "$DUMP_OK"
pg_restore --list "$DUMP_FILE" > "$dump_lab/archive-list"
pg_restore --exit-on-error --single-transaction --dbname=restored_db "$DUMP_FILE"
counts='SELECT (SELECT count(*) FROM customers), (SELECT count(*) FROM orders)'
test "$(psql -X -Atc "$counts")" = '2|2'
test "$(psql -X -d restored_db -Atc "$counts")" = '1|1'
test "$(psql -X -d restored_db -Atc 'SELECT count(*) FROM orders o LEFT JOIN customers c ON c.id=o.customer_id WHERE c.id IS NULL')" = 0
psql -X -d restored_db -v ON_ERROR_STOP=1 -c \
 'SELECT c.name,o.id FROM customers c JOIN orders o ON o.customer_id=c.id'
pg_dump --version
printf 'PASS: source=2|2 restored=1|1 orphan_orders=0\n'

第一个会话导出快照时，库中只有一位客户和一笔订单。在该事务保持打开时，第二个会话提交另一组有关联的数据。pg_dump 明确导入较早快照，所以恢复后计数是 1|1，源库当前计数则为 2|2。关联查询返回名为 before 的客户和十号订单，悬空订单检查结果为零。这样验证的是确定的并发时序，不依赖导出恰好跑得够慢。

PostgreSQL 18.6 上完整恢复与断言均通过。嵌套 shell 只有在写入和 dump 都成功后才创建标记，防止 psql 在外部命令失败后继续运行而掩盖失败。这个实验验证夹具中的快照选择和恢复，不代表已经测出真实应用的恢复时间。生产备份仍需保留实际恢复演练、归档校验值、留存策略与依赖记录，才能让一次成功导出成为可审阅的恢复能力。

来源

PostgreSQL pg_dump，快照、格式、范围与版本兼容，已核验 2026-09-10。
PostgreSQL pg_restore，恢复错误处理和事务选项，已核验 2026-09-10。

NOW 与 clock_timestamp 的差别在冻结时机

Thu, 13 Jan 2028 00:00:00 +0000

PostgreSQL 提供多种“当前时间”。事务时间标记事务开始，语句时间标记客户端命令到达，墙钟读数则在表达式求值时读取当前时钟。选择不同函数，会改变审计字段、过期检查和长任务中间观测的含义。应先明确要记录哪个事件，再决定函数，不能因为名称都有时间含义就随意互换。

一个事务只有一个开始时刻

now()、transaction_timestamp() 与不带精度参数的 CURRENT_TIMESTAMP，返回同一个事务开始瞬间。在显式事务里，它们始终固定，即使后续语句已经晚了几秒或几分钟。CURRENT_TIMESTAMP 可以指定精度来舍入结果；小数位数的处理与采样时刻是两回事，不能因为显示精度不同就推断时钟来源改变。

这种稳定性适合让相关行共享同一个逻辑事务时间。它不记录每行真正插入的时刻，也不是最终提交时间。事务可能先等待锁或执行大量计算，随后才插入数据，最后还有可能回滚。把列命名为 created_at，并不能自动说明默认值到底代表哪个事件，需要在数据契约里写清楚。

普通自动提交模式下，连续语句通常各自处于不同事务，因此 now 看起来会随每条语句前进。但这种观察没有改变函数契约。后来为了原子性加上显式事务时，原本被误认为实时变化的时间，就可能暴露出早已固定的问题；验证时应覆盖真实事务边界，而不只在交互终端连续敲两条查询。

语句标记与实时读数

statement_timestamp() 返回服务器收到最近一条客户端命令消息的时间，在该命令执行期间保持稳定。事务中后续命令的语句时间可能与事务时间不同。同一协议消息里发送的多条 SQL 命令，也可能共享这个标记，所以它不一定代表等待结束后，每个内部操作真正开始的那一刻。

clock_timestamp() 在求值时读取当前墙钟，即使同一条语句内部也可能变化。由于时钟精度有限，两次调用并不保证得到不同值。它也不是单调计时器，时钟校正可能影响前后读数的差值。需要保证耗时测量不受墙钟调整影响时，应使用合适的单调时钟，而不是把数据库墙钟当成无条件递增的计数器。

这些值单独使用，都不能证明并发事务的提交顺序，也不能提供唯一事件身份。相关字段需要一致逻辑时间时选事务标记，观测命令到达时选语句标记，需要读取当前墙钟时才选实时观测。身份与顺序要求应另外明确，不能让时间戳自动承担它未承诺的语义。

坏掉的样子

长事务中的过期检查如果使用 now，就会持续与事务开始时刻比较。一个在事务开始时成立的条件，即使真实墙钟已经越过截止时间，也可能继续成立。反过来，把全部默认值换成 clock_timestamp，又可能让本该共享逻辑创建时间的相关行各不相同。修改函数前，应先确定列代表的是业务批次、命令到达还是实际观测。

列默认值中的特殊字面量 TIMESTAMPTZ 'now' 也是一个陷阱。PostgreSQL 在解析常量时就把它转换成时间，所以后续插入可能一直拿到建表时刻。DEFAULT now() 是函数调用，会在真正使用默认值时求值。两种写法看起来相似，并不代表求值生命周期相同；只检查默认表达式包含 now 这个词，会漏掉这个差别。

这些函数返回 timestamptz。切换会话时区会改变瞬间的显示形式，而不是改变已存储的瞬间本身。timestamptz 不保留最初传入的时区名称；应用需要记住原始时区时，应单独建模，不能从后来显示的偏移量反推原始地区。相同偏移量也不足以唯一确定某个时区名称。

快速验证

把下面内容保存为 timestamps.sql，在可丢弃的 PostgreSQL 18 数据库中执行 psql -X -v ON_ERROR_STOP=1 -f timestamps.sql。显式事务之外，应保持 psql 默认的自动提交行为；第二段需要让两次插入分别处在不同事务里。所有表都是临时表。

\set ON_ERROR_STOP on
BEGIN;
SET LOCAL timezone='UTC';
CREATE TEMP TABLE moments (step integer,tx timestamptz,statement timestamptz,wall timestamptz);
INSERT INTO moments VALUES (1,now(),statement_timestamp(),clock_timestamp());
SELECT pg_sleep(0.03);
INSERT INTO moments VALUES (2,CURRENT_TIMESTAMP,statement_timestamp(),clock_timestamp());
SELECT step,tx,statement,wall FROM moments ORDER BY step;
SELECT min(tx)=max(tx) AS one_transaction_time,
 count(DISTINCT statement)=2 AS two_statement_times FROM moments;
SELECT now()=transaction_timestamp() AND now()=CURRENT_TIMESTAMP AS aliases;
SELECT extract(epoch FROM now()) AS instant_utc;
SET LOCAL timezone='Asia/Shanghai';
SELECT now() AS same_instant_different_display,extract(epoch FROM now()) AS instant_shanghai;
DO $$ BEGIN
 IF (SELECT min(tx)=max(tx) FROM moments) IS DISTINCT FROM true THEN
 RAISE EXCEPTION 'transaction time changed';
 END IF;
 IF now() IS DISTINCT FROM transaction_timestamp() THEN RAISE EXCEPTION 'aliases differ'; END IF;
 IF (SELECT tx FROM moments WHERE step=1) IS DISTINCT FROM now() THEN
 RAISE EXCEPTION 'time zone changed the instant';
 END IF;
END $$;
ROLLBACK;
CREATE TEMP TABLE defaults_demo (
 id integer,
 parsed timestamptz DEFAULT TIMESTAMPTZ 'now',
 called timestamptz DEFAULT now()
);
INSERT INTO defaults_demo (id) VALUES (1);
SELECT pg_sleep(0.03);
INSERT INTO defaults_demo (id) VALUES (2);
SELECT id,parsed,called FROM defaults_demo ORDER BY id;
SELECT min(parsed)=max(parsed) AS one_parsed_constant,
 count(DISTINCT called)=2 AS two_insert_transaction_times FROM defaults_demo;
DO $$ BEGIN
 IF (SELECT min(parsed)=max(parsed) FROM defaults_demo) IS DISTINCT FROM true THEN
 RAISE EXCEPTION 'parsed default was evaluated again';
 END IF;
END $$;
DROP TABLE defaults_demo;

PostgreSQL 18.6 实测中，前两行共享相同 tx，但 statement 和 wall 读数不同；别名比较返回真。从 UTC 切换到 Asia/Shanghai 后，显示偏移变成东八区，但两次 epoch 值完全一致。断言检查事务时间稳定，并确认时区切换没有改变同一个瞬间，而不是仅凭显示字符串判断。

回滚第一段后，默认值实验在两个独立事务中分别插入一行。两行 parsed 保留相同的解析期常量，而 called 随插入事务变化。短暂休眠是为了让本次差别容易观察，并不保证时钟分辨率或调度延迟。最后的 DROP 清除第二张临时表；如果断言提前终止，连接结束也会清理临时对象，实验不会留下持久业务数据。

来源

PostgreSQL 日期时间函数，事务、语句、墙钟和默认值求值语义，已核验 2026-09-10。
PostgreSQL 日期时间类型，timestamptz 存储、显示和特殊输入字面量，已核验 2026-09-10。

checkpoint 把脏缓冲刷到磁盘

Thu, 06 Jan 2028 00:00:00 +0000

检查点为 PostgreSQL 崩溃恢复建立一个可用起点。它同步这个检查点所需的数据文件变更，并记录相应恢复信息。依赖某段日志的数据页写出之前，相关 WAL 必须先持久化。这样的顺序让事务提交不必每次都把全部修改过的表页立即刷到磁盘；发生崩溃时，再从恢复起点重放后续必要变更。

坏掉的样子

检查点不是事务提交。数据页可以包含尚未提交事务写入的版本，读者究竟能看到哪些行，仍然由可见性与事务状态决定。检查点完成，不会把这些写入变成已提交，也不会把随手复制一份正在变化的数据目录变成有效基础备份。并发活动还可能再次弄脏页面，所以不能把完成提示理解成缓冲池从此全部干净。

日志保留也有别的限制。最大 WAL 大小是与自动检查点调度有关的软目标，不是磁盘使用硬上限；归档失败或复制槽保留，都可能让日志超过这个值。最小 WAL 大小则涉及回收并预留文件供以后复用，不是另一条强制触发检查点的阈值。如果理解错这些参数，可能一边看到检查点间隔正常，一边忽略实际上还在持续增长的归档积压。

快速验证

准备一台安静的 PostgreSQL 18 可丢弃实例，开启甲、乙两个全新的 psql -X -v ON_ERROR_STOP=1 会话。显式检查点和控制文件信息使用具有相应权限的管理角色。保留正常开启的同步落盘与同步提交设置。乙先创建计数器，并保存当前检查点位置：

SHOW fsync;
SHOW synchronous_commit;
CREATE SCHEMA checkpoint_demo;
CREATE TABLE checkpoint_demo.items (id integer PRIMARY KEY,n integer);
INSERT INTO checkpoint_demo.items VALUES (1,10);
CREATE TABLE checkpoint_demo.baseline AS
SELECT checkpoint_lsn FROM pg_control_checkpoint();

显示的两个设置都应为开启，初始已经提交的值是十。甲在一个保持打开的事务中把它改成九十九：

BEGIN;
UPDATE checkpoint_demo.items SET n=99 WHERE id=1 RETURNING n;

甲从自己的更新得到九十九，但此时不要提交。乙请求检查点，并查看普通读者可见的值：

CHECKPOINT;
SELECT c.checkpoint_lsn>b.checkpoint_lsn AS checkpoint_advanced,
 (SELECT n FROM checkpoint_demo.items WHERE id=1) AS visible_value
FROM checkpoint_demo.baseline AS b CROSS JOIN pg_control_checkpoint() AS c;

检查点位置推进了，乙仍然读到十。维护工作已经完成，甲的事务却还没有决定提交还是回滚。这把数据库维护的进度与业务操作的提交状态明确区分开来，不能把其中一个完成信号当成另一个完成的证据。回到甲，核对自己的版本仍然可见，然后丢弃这次修改：

SELECT n FROM checkpoint_demo.items WHERE id=1;
ROLLBACK;

甲回滚前仍读到九十九。乙现在确认值恢复为原来的十，再完成一次普通提交，并在这次操作紧邻的位置记录前后检查点标识：

SELECT n FROM checkpoint_demo.items WHERE id=1;
UPDATE checkpoint_demo.baseline
SET checkpoint_lsn=(SELECT checkpoint_lsn FROM pg_control_checkpoint());
UPDATE checkpoint_demo.items SET n=11 WHERE id=1;
SELECT c.checkpoint_lsn=b.checkpoint_lsn AS no_new_checkpoint,
 (SELECT n FROM checkpoint_demo.items WHERE id=1) AS committed_value
FROM checkpoint_demo.baseline AS b CROSS JOIN pg_control_checkpoint() AS c;
DO $$ BEGIN
 IF (SELECT n FROM checkpoint_demo.items WHERE id=1) IS DISTINCT FROM 11 THEN
 RAISE EXCEPTION 'checkpoint/transaction boundary result mismatch';
 END IF;
END $$;
DROP SCHEMA checkpoint_demo CASCADE;

本次短调度的结果先是十，随后检查点未变化的比较为真，已经提交的值是十一。普通提交成功，并没有请求另一个检查点。在繁忙实例里，独立调度的检查点可能恰好改变这个比较结果，但不会改变提交本身的语义。断言核对最终行值，实验结束后删除自己的模式。

这个演练验证的是事务可见性与检查点边界，没有测量恢复耗时，也没有模拟存储设备丢失已经确认写入的情况。持久性契约仍然依赖正确开启的相关设置，以及能够履行同步请求的存储。要判断实际恢复时间是否满足目标，需要另做基于真实保留工作量的崩溃恢复演练，不能从这几条查询完成得快直接推导出来。

同时考虑恢复与前台负载

延长检查点间隔，可能减少重复刷写，并在开启整页写入时减少一部分重复整页日志；崩溃后需要重放的工作也可能随之增加。检查点过于频繁，又可能提高日志和数据写流量，影响请求延迟。存储是快速本地磁盘，并不能单独证明更长的间隔就符合业务恢复目标，还是需要以测量作取舍。

完成目标参数把常规检查点工作分散到间隔中的某个比例，常用的九成是节奏目标，不是任何负载下都没有延迟尖峰的保证。应把检查点持续时间、请求触发与定时触发次数、日志增长和前台延迟结合起来看。调小参数使任务更快完成，也可能意味着同一批写入挤在更短窗口里，不能只看完成时长缩短就认为代价下降。

在 PostgreSQL 18 中，检查点计数和写入、同步时间位于专门的检查点统计视图；后台写进程视图描述的是另一个组件。频繁由日志增长触发请求时，先判断是正常写入量、配置目标还是保留链路造成，再修改限额。最终应比较恢复测试和业务延迟，让调优结论对应实际达到的恢复能力，而不是只对应一个看起来整齐的参数值。

来源

PostgreSQL 18 WAL 入门，预写顺序及无需立即刷出所有数据文件的提交持久性，已核验 2026-09-11。
PostgreSQL 18 CHECKPOINT，显式检查点行为与所需权限，已核验 2026-09-10。
PostgreSQL 18 WAL 配置，检查点调度、写入节奏和日志大小语义，已核验 2026-09-10。
PostgreSQL 18 累计统计，专门的检查点统计视图，已核验 2026-09-10。

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。

Postgres 流式复制让备用节点保持温热

Tue, 10 Aug 2027 00:00:00 +0000

物理流复制把 PostgreSQL WAL 发送到备库，备库通过重放记录维持集群的另一份副本。发送不必等待整个日志段结束。这与选择部分表变更进行传送的逻辑复制不同。接收进程正在运行、备库可以连接，都是有价值的健康信号，但任何一个信号都不能单独证明某条已经提交的业务记录此刻在备库可见。

坏掉的样子

流复制默认是异步的。主库可以先向客户端确认提交，备库之后才收到或应用相关记录。若主库恰好在这个窗口丢失，切换到备库时可能丢掉最近已经确认的工作。备库也可能保持连接并持续接收日志，却由于暂停回放而一直返回旧行。因此网络交付在推进，并不能证明查询新鲜度也在推进。

应区分不同进度标记。备库的接收位置函数报告通过流复制已经接收并同步到磁盘的位置，回放位置函数则报告已经应用的位置，两者差值可以暴露回放积压。最后一次重放事务的时间戳，即使在完全空闲的系统上也会不断变旧；单纯用当前时间减去它，不能可靠判断究竟有多少尚未处理的工作。

快速验证

使用非超级操作系统账户，在 Linux 环境中准备 PostgreSQL 18 服务端与客户端程序。本脚本已经在 PostgreSQL 18.6 上执行。它创建私有临时集群及 Unix 套接字目录，不打开网络监听。本地信任认证仅用于这些可丢弃的实验实例。少量日志预留支持这个有界演练，脚本没有配置永久复制槽。

#!/bin/sh
set -eu
umask 077
lab=$(mktemp -d /tmp/xbcatm-streaming.XXXXXX)
mkdir "$lab/socket"
primary=$lab/primary
standby=$lab/standby
cleanup() {
 for cluster in "$standby" "$primary"; do
 if test -f "$cluster/postmaster.pid"; then
 pg_ctl -D "$cluster" -m fast -w stop >/dev/null
 fi
 done
}
trap cleanup EXIT
initdb -D "$primary" --no-locale --encoding=UTF8 --auth-local=trust --auth-host=reject >/dev/null
cat >> "$primary/postgresql.conf" <<CONF
listen_addresses = ''
unix_socket_directories = '$lab/socket'
port = 56432
wal_level = replica
max_wal_senders = 4
wal_keep_size = '64MB'
CONF
pg_ctl -D "$primary" -l "$lab/primary.log" -w -t 15 start >/dev/null
export PGHOST=$lab/socket PGPORT=56432 PGDATABASE=postgres PGUSER=$(id -un)
export PGCONNECT_TIMEOUT=2
psql -X -v ON_ERROR_STOP=1 -qAt <<'SQL'
CREATE TABLE marker (id integer PRIMARY KEY,value text);
INSERT INTO marker VALUES (1,'base');
SQL
pg_basebackup -D "$standby" -R -X stream -c fast -w
cat >> "$standby/postgresql.conf" <<CONF
port = 56433
hot_standby = on
CONF
pg_ctl -D "$standby" -l "$lab/standby.log" -w -t 15 start >/dev/null
PGPORT=56433 psql -X -v ON_ERROR_STOP=1 -qAt -c 'SELECT pg_wal_replay_pause()' >/dev/null
attempt=0
while test "$(PGPORT=56433 psql -X -v ON_ERROR_STOP=1 -qAt -c "SELECT pg_get_wal_replay_pause_state()='paused'")" != t; do
 attempt=$((attempt+1))
 test "$attempt" -lt 100 || { echo 'replay did not pause' >&2; exit 1; }
 sleep 0.1
done
psql -X -v ON_ERROR_STOP=1 -qAt -c "INSERT INTO marker VALUES (2,'later')"
target=$(psql -X -v ON_ERROR_STOP=1 -qAt -c 'SELECT pg_current_wal_lsn()')
attempt=0
while test "$(PGPORT=56433 psql -X -v ON_ERROR_STOP=1 -qAt -c "SELECT pg_last_wal_receive_lsn()>='$target'::pg_lsn")" != t; do
 attempt=$((attempt+1))
 test "$attempt" -lt 150 || { echo 'receiver did not catch up' >&2; exit 1; }
 sleep 0.1
done
psql -X -v ON_ERROR_STOP=1 -qAt -c 'SELECT state,sync_state FROM pg_stat_replication'
PGPORT=56433 psql -X -v ON_ERROR_STOP=1 -qAt <<SQL
SELECT pg_last_wal_receive_lsn()>='$target'::pg_lsn,
 pg_last_wal_replay_lsn()<'$target'::pg_lsn,
 (SELECT count(*) FROM marker);
DO \$\$ BEGIN
 IF (pg_last_wal_receive_lsn()>='$target'::pg_lsn
 AND pg_last_wal_replay_lsn()<'$target'::pg_lsn
 AND (SELECT string_agg(id||':'||value,',' ORDER BY id) FROM marker)='1:base')
 IS NOT TRUE THEN
 RAISE EXCEPTION 'paused replay result mismatch';
 END IF;
END \$\$;
SQL
echo stale_read_while_receiving
PGPORT=56433 psql -X -v ON_ERROR_STOP=1 -qAt -c 'SELECT pg_wal_replay_resume()' >/dev/null
attempt=0
while test "$(PGPORT=56433 psql -X -v ON_ERROR_STOP=1 -qAt -c "SELECT pg_last_wal_replay_lsn()>='$target'::pg_lsn")" != t; do
 attempt=$((attempt+1))
 test "$attempt" -lt 150 || { echo 'replay did not catch up' >&2; exit 1; }
 sleep 0.1
done
PGPORT=56433 psql -X -v ON_ERROR_STOP=1 -qAt <<'SQL'
SELECT id,value FROM marker ORDER BY id;
DO $$ BEGIN
 IF (SELECT string_agg(id||':'||value,',' ORDER BY id) FROM marker)
 IS DISTINCT FROM '1:base,2:later' THEN
 RAISE EXCEPTION 'resumed replay result mismatch';
 END IF;
END $$;
SQL
pg_ctl -D "$primary" -m fast -w stop >/dev/null
echo old_primary_stopped
pg_ctl -D "$standby" -w -t 15 promote >/dev/null
PGPORT=56433 psql -X -v ON_ERROR_STOP=1 -qAt <<'SQL'
SELECT pg_is_in_recovery();
INSERT INTO marker VALUES (3,'promoted');
SELECT id,value FROM marker ORDER BY id;
DO $$ BEGIN
 IF pg_is_in_recovery() OR (SELECT count(*) FROM marker)<>3 THEN
 RAISE EXCEPTION 'promotion result mismatch';
 END IF;
END $$;
SQL
printf 'lab_directory %s\n' "$lab"

脚本通过带恢复配置选项的物理基础备份建立副本，这个选项会写入备库连接信息并创建备库信号文件。副本在另一个套接字端口启动后，先请求暂停回放，再等待状态确实变成已经暂停。随后主库提交第二行，并捕获提交之后的日志位置，作为接收与回放比较的明确目标。

主库的预期状态是正在流复制且采用异步确认。备库输出的两个真值与行数一，分别表示接收已经到达目标、回放仍未到达、表里只有原始一行。断言还会检查这一行的实际内容。因此“仍在接收时读到旧数据”的标记来自数据库真实查询结果，并不是在应用缓存中人为伪造一段延迟。

恢复回放之后，脚本等待回放位置达到目标，再核对第一行为 base、第二行为 later。每次观察都使用新连接，排除了先前打开的事务快照导致旧结果的干扰。真实应用中的长事务如果继续持有旧快照，即使备库已经回放到新位置，也可能还需要结束那个事务才能读到新版本；这是另一条需要单独识别的可见性边界。

接管步骤先停止旧主库，再提升备库并等待提升完成。恢复状态变为假，第三行写入后得到 promoted，断言验证新主库确实接受了这次写入。所有实验服务都会在退出时停止，打印目录保留日志。这验证的是隔离环境里的有序提升，没有验证自动故障探测、网络分区处理或客户端地址迁移，不能据此宣称整套高可用切换已经完成。

明确确认与保留契约

同步复制既需要选择同步备库，也需要相关事务同步提交设置。仅把事务选项设为开启，而没有选择任何同步备库，不会凭空增加远端确认要求。配置好同步备库之后，普通开启模式等待它们持久化日志；远端写入模式等待写入对方操作系统；远端应用模式等待对方重放。这些选择改变的不只是持久性与读取可见性，也包括提交延迟以及备库不可用时的服务可用性。

日志保留是另一项独立义务。复制槽可以保留断线接收者仍需要的日志，但消费者长期停滞时，若没有有意识地设置限制与监控，也可能耗尽磁盘。没有足够保留日志或可用归档时，过旧的备库可能只能重建。应联合观察日志生成、接收、回放、保留字节数与剩余空间，不要只看某一个复制进程是否还活着。

提升本身不会隔离另一个仍然写入的主库。生产故障切换必须阻止旧写入者继续服务，选择可接受的恢复位置，重定向客户端，并通过受支持的重建或回绕流程让原主库重新加入。否则两个独立写入者可能产生分叉。一个健康的流复制连接只证明其中一部分机制正在工作，不能替代完整接管流程及其业务数据核验。

来源

PostgreSQL 18 温备与流复制，异步交付、同步确认、日志保留与故障切换，已核验 2026-09-10。
PostgreSQL 18 管理函数，接收和回放位置、实际暂停状态及提升语义，已核验 2026-09-10。
PostgreSQL 18 pg_basebackup，使用恢复配置选项创建备库，已核验 2026-09-10。

Postgres 连接很贵，要复用与池化

Mon, 09 Aug 2027 00:00:00 +0000

温热的连接池能够减少反复建立 PostgreSQL 连接，但空闲连接在池里等待期间也可能消失。服务器结束会话、网络故障或中间设备的空闲策略，都可能让客户端仍握着一个已经不能使用的套接字。复用方案必须包含失效识别和替换；对象还在池里，只说明应用保存了它，不能证明下一条查询一定成功。

坏掉的样子

TCP 保活能够识别原本空闲连接上的部分故障，却不会替 SQL 设置执行截止时间，也不证明数据库能够完成某个具体请求，更不会处理结果未知的提交。客户端连接参数只作用于 TCP，使用 Unix 域套接字时相关选项会被忽略；服务器端保活设置控制的是另一端。具体操作系统是否支持某个选项，也会影响最终行为，不能只看参数字符串存在就宣称故障检测已经发生。

借出前健康检查，可以在把连接交给调用方之前识别已经失效的连接。Psycopg 默认不执行这种检查，但提供回调让应用选择启用。多一次探测意味着额外往返，也仍然无法阻止连接在探测成功后立刻出故障。因此，建立连接、等待租用和执行语句，都需要各自的预算与错误处理，不能用一个“保活开启”覆盖全部阶段。

快速验证

准备 Python 3.10 或更新版本，通过 TCP 连接使用默认零值语句超时的 PostgreSQL 18，并安装本次验证版本：python3 -m pip install "psycopg[binary]==3.3.5" "psycopg-pool==3.3.1"。把 PG_DSN 设置为可丢弃数据库，使用允许结束自己后台连接的角色。保存为 liveness-demo.py 后运行。程序先记录每个测试池刚创建的连接标识，然后只结束那条已经归还、处于空闲状态的连接：

import os

import psycopg
from psycopg.errors import QueryCanceled
from psycopg_pool import ConnectionPool

dsn = os.environ['PG_DSN']
with psycopg.connect(dsn, autocommit=True) as admin:
 for checked in (False, True):
 with ConnectionPool(
 dsn, min_size=1, max_size=1, timeout=3, open=True,
 check=ConnectionPool.check_connection if checked else None,
 kwargs={
 'connect_timeout': 2,
 'keepalives': 1,
 'keepalives_idle': 30,
 'keepalives_interval': 10,
 'keepalives_count': 3,
 },
 ) as pool:
 pool.wait(timeout=3)
 with pool.connection() as conn:
 assert conn.execute('SELECT inet_server_addr() IS NOT NULL').fetchone()[0]
 original_pid = conn.info.backend_pid
 parameters = conn.info.get_parameters()
 assert [parameters[k] for k in (
 'keepalives', 'keepalives_idle', 'keepalives_interval', 'keepalives_count'
 )] == ['1', '30', '10', '3']
 # Terminate only the idle connection just created by this fixture.
 assert admin.execute('SELECT pg_terminate_backend(%s,2000)', (original_pid,)).fetchone()[0]

 if not checked:
 try:
 with pool.connection() as conn:
 conn.execute('SELECT 1')
 except psycopg.OperationalError as error:
 print('unchecked_first_use', error.sqlstate)
 else:
 raise AssertionError('terminated connection unexpectedly worked')

 with pool.connection() as conn:
 replacement_pid = conn.info.backend_pid
 assert replacement_pid != original_pid
 assert conn.execute('SELECT 1').fetchone()[0] == 1
 print('checked', checked, 'replacement', True)

 try:
 with pool.connection() as conn:
 conn.execute("SET LOCAL statement_timeout='50ms'")
 conn.execute('SELECT pg_sleep(0.2)')
 except QueryCanceled as error:
 assert error.sqlstate == '57014'
 print('statement_timeout', error.sqlstate)
 else:
 raise AssertionError('long statement did not time out')

 with pool.connection() as conn:
 assert conn.info.backend_pid == replacement_pid
 assert conn.execute('SHOW statement_timeout').fetchone()[0] == '0'
 assert conn.execute('SELECT 1').fetchone()[0] == 1
 print('healthy_after_rollback', True)

两种情况都配置了客户端保活参数，并核对有效值，不打印整个连接串。第一种没有借出前检查。空闲后端被服务器结束后，下次读取遭遇操作错误；本次这种明确的服务器关闭返回 57P01。池随后丢弃坏连接，下一次借用得到不同的后端标识，并成功返回一。

第二种启用内置的连接检查回调。经过同样的受控终止，获取阶段发现旧连接不能使用，再把正常的新连接交给借用者。两种情况最后都报告完成替换，但只有未检查的那一种，把首次使用旧连接的错误直接暴露给业务代码。这个实验验证的是显式服务器终止，不是静默网络分区，也没有等待 TCP 保活探测计时器真正触发。

每种情况还会在五十毫秒的事务局部语句预算下，执行二百毫秒睡眠，预期得到 57014。此时连接仍然活着，TCP 保活也已启用，查询却依旧需要自己的截止时间。异常离开连接上下文后，失败事务被回滚；后续借用继续使用同一个替代后端，看到语句超时恢复为原来的零，并能正常读取一。

这些检查区分了两件事：死连接需要替换，活连接上的语句取消则可以通过正确事务清理恢复。实验还确认局部超时设置没有泄漏给下一位借用者。不能把所有 SQL 错误都当成必须销毁连接的证据，也不能因为健康探测成功，就删除执行阶段的预算。判断应跟随错误发生的阶段，以及对应连接和事务的真实状态。

在明确的操作边界重新连接

池的最大空闲时间和最大寿命，有助于管理连接轮换，但都不能保证套接字一定活到设置的年龄。服务器或中间设备可能更早关闭连接。应协调这些策略，观察丢弃、重连次数和故障期间的获取延迟；健康检查过于频繁，也会给大量短查询增加不可忽略的往返成本。策略需要结合请求长度和故障特征，而不是越积极越可靠。

示例是在应用写入开始之前替换空闲连接。提交期间断连则不同：数据库可能已经提交，只是确认丢失。建立新连接不会自动告诉调用方上一笔究竟成功没有，直接重放写入就可能重复副作用。应保留稳定操作标识，并查询持久化结果，在结果得到核实后再决定是否重发非幂等工作。

获取连接的多次尝试，还应受调用方取消和请求总截止时间控制，避免请求已经结束，后台重连仍然不停消耗资源。保活、健康检查、获取预算和语句预算可以共同工作，但每一项都只回答自己的问题；把它们对应到具体操作边界，才能知道错误之后应该替换连接、回滚事务，还是先核对已经提交的结果。

来源

PostgreSQL 18 libpq 连接参数，客户端保活、套接字适用范围与连接选项，已核验 2026-09-10。
Psycopg 连接池文档源码，借出前检查与失效连接替换，已核验 2026-09-10。
Psycopg 连接池 API 文档源码，可选检查回调与连接生命周期控制，已核验 2026-09-10。
PostgreSQL 18 客户端连接默认值，语句超时与连接存活的不同边界，已核验 2026-09-10。

Postgres 序列用一个缓存发号

Mon, 02 Aug 2027 00:00:00 +0000

一个序列在锁下逐个返回数字，缓存则把一大批小锁调用，变成偶发的大幅跳跃。只这一个设计决定——用短锁保正确、用批量换速度——就解释了序列带来的所有意外：重启后的空号、并发下的交错编号、审计敏感表里对不上的号码。没有一条是缺陷，全都源于把它当成高速唯一发号器，而不是里程表。

实际影响可以写成一句直白的契约：序列保证同一序列内唯一、数值大致递增、支持高并发；不保证连续、不保证跨会话单调、不保证已分配未用的号码在崩溃后存活。按真实契约建模，序列就从操心清单里消失；按想象中的里程表建模，每个空号都会变成一次事故。

每次拿一个数字都加锁

序列保存一个计数器，nextval 在其上加一行锁并把计数值推进，于是每次调用都竞争同一个值。在高并发插入时，这里会成为热点。每个后端都要短暂串行地经过同一行去领号，加多少 worker 都突破不了这个上限。锁很短——加一就放——但每秒几万次插入时，再短的串行也是串行。

所以批量导入和并发写入总是最先感受到序列的存在。表可以并行插，索引可以分裂，计数器一次只接待一个领号的人。性能分析通常也能证实：锁等待堆在序列对象上，别处都在空转。序列成了瓶颈时，解法不是更快的锁，而是少去几趟——这正是缓存要买的东西。

缓存换速度、留空洞

开了缓存，调用方一次把一整套拿回家，只在补货时才回到序列，锁的往返大幅减少。但一次重启会把这批还没用完的部分丢掉，所以缺号是设计上的结果。缓存设一百，意味着一百个号码才做一次加锁访问，而不是一个一访——竞争降两个数量级，代价是每次崩溃或切换最多丢一百个号。

缓存大小按插入速率定，别按审美定。缓存为一，空号最少但每次都要加锁；缓存一千，序列基本退出并发舞台，但每次重启能跳一千个号。多数在线交易负载落在二三十到一百之间：锁从性能画像里消失，空号小到没人察觉。用修改序列语句调整，这个设置长在序列自己身上，所以随备份走，从库行为也一致。

序列值还不属于事务快照。事务拿到号码后即使随后回滚，序列也不会倒退；多个会话同时调用时，较大的号码也不代表较早提交。主备切换、批量导入和失败重试都会留下正常的间隙。把序列列当作不可变的技术标识，时间顺序另用提交时间或事件编号表达。若财务流程确实要求连续票号，单独建立窄范围的提交计数器，并接受那里必须串行的成本，别让主键承担两种互相冲突的承诺。

当它是唯一值，别当连续号

序列产生的是唯一 id，绝不是无缝的 1、2、3，缺口完全可以接受。只有真正必须连续的地方才去保号；序列只当作 id 生成器使。空号有三个来源：回滚的事务、重启丢掉的缓存批、并发会话交错领号——三个都正常，一个都挡不住，除非交出并发或崩溃安全。

连续编号是法规或业务硬要求的地方——发票号、排队票——就显式另建机制：提交时在一个短事务里推进的独立计数表，只在这条窄路上承受串行代价。主键用高速且有空号的序列，对外展示的编号用慢而无缝的计数器。把两份工作塞进一个机制，等于逼自己在速度和连续之间二选一，而两种负载其实哪边都不想要对方的答案。

坏掉的样子

经典故障是审计恐慌：切换主库后财务发现发票号跳了几百，怀疑丢了数据。其实什么都没丢——备库提升时开了新的缓存窗口，旧的那批缓存随着主库一起走了。修法是沟通加隔离：文档里写明代理键会跳号，绝不把序列裸值暴露到会被人读出连续含义的地方。号码要见人，就给它配显式的无缝计数器，别用大缓存的序列顶。

第二种故障更隐蔽：两个会话领到交错的号，应用代码却假设编号靠后等于提交靠后。并发下会话甲先领到一百零一、后提交，会话乙后领到一百零二、先提交。按编号排序就排错了历史。提交顺序重要时，按提交时间戳排序，永远别按序列值。

快速验证

验证缓存行为与空号来源：

SHOW SERVER_VERSION;
SELECT cache_size FROM pg_sequences WHERE sequencename = 'orders_id_seq';
BEGIN; SELECT nextval('orders_id_seq'); ROLLBACK;
SELECT last_value FROM orders_id_seq;

回滚照样推进序列，证明空号是结构使然，不是故障所致。

来源

PostgreSQL 序列函数，序列函数与缓存的官方文档，已核验 2026-06-01。
PostgreSQL 创建序列，记录缓存等序列选项，已核验 2026-09-05。

Postgres JSONB 搭配 GIN 做灵活查询

Wed, 28 Jul 2027 00:00:00 +0000

PostgreSQL 的 JSONB 列可以容纳形态不同的文档，但高效查询仍要求条件与索引有准确的对应关系。对整篇文档建立 GIN 索引，只能支持特定的 JSONB 算子，不能自动加速所有从文档提取字段的表达式。先确定数据类型和查询语义，再选择索引，才能避免建完索引却没有收益。

让算子与索引对应

包含条件 payload @> '{"status":"pending"}' 检查文档是否包含该键及对应的 JSON 字符串值。采用默认 jsonb_ops 操作符类时，整列 GIN 可以支持包含、顶层键存在判断，以及能够提取索引条件的 JSON 路径查询。索引保存可检索的组成部分；位图堆扫描仍可能访问表，并重新检查候选行，不能把它理解为完全不用回表。

payload->>'status' = 'pending' 则是在比较提取后的文本。payload 上的 GIN 并不是这个文本表达式的索引。对 (payload->>'status') 建立 B-tree 表达式索引，才与标量等值查询对应。如果很多查询需要对 status 排序、关联或施加约束，独立的有类型列可能更清楚，也能减少不断从灵活文档中推导字段的成本。

不能未经类型检查，就把所有文本条件改写成包含条件。JSON 数字和 JSON 字符串经过文本提取后可能得到相同文本，但包含算子会区分它们的 JSON 类型。只有数据约束保证相关前提时，改写才等价。应用应通过数据库驱动绑定参数，而不是把不可信输入拼接进 SQL 或 JSON 字符串；索引选择和输入处理需要分别正确。

操作符类也决定能力边界。jsonb_path_ops 支持包含以及适用的路径匹配，但不支持 jsonb_ops 提供的键存在算子。对合适数据，它可能更小、选择性更好，却不是无条件更优的替代品。同样，嵌套表达式索引必须对应实际使用的表达式，给完整文档建索引，并不意味着提取后的每棵子树都自动有独立索引。

缺失和空值是不同问题

键不存在、键对应 JSON null、键对应字符串“null”，是三种状态。存在判断会把后两种都视为存在。用 -> 提取 JSON 时，缺失键得到 SQL NULL，显式 null 得到 JSON null 值。用 ->> 提取文本时，缺失与 JSON null 都变成 SQL NULL，而字符串仍保留为文本。这些差别会影响过滤、唯一性假设和应用默认值。

如果业务关心键是否出现，应使用键存在检查；如果字段必须是字符串或数字，还要检查 JSON 类型。用普通等号和 NULL 比较，不能表达“键不存在”。另外，? 只检查顶层，不会递归查找文档任意深度的同名键。查询内部对象时，必须明确路径及对应索引，不能因某处存在同名键就认为顶层条件成立。

坏掉的样子

常见性能问题是建了 GIN，却保留不兼容的文本提取条件。另一个错误是认为索引只要适用，就一定会被选择。统计信息、选择性、表大小和成本估计都会影响计划；读取大部分数据时，顺序扫描可能合理。应先比较估计行数与实际行数，再判断问题是估计偏差、条件不匹配，还是索引本身收益不足。

大型灵活文档也会增加写入工作。GIN 要维护许多条目，更新文档依然是更新一行，会付出相应的锁和存储成本。应围绕真实负载的问题建立索引，不要为假想查询覆盖整篇文档。JSONB 语法合法，也不能证明必要业务字段存在或类型正确；这些要求要由实际契约和校验承担。

快速验证

把下面内容保存为 json-query.sql，在可丢弃的 PostgreSQL 18 数据库中执行 psql -X -v ON_ERROR_STOP=1 -f json-query.sql。实验在事务中创建临时数据，末尾回滚清除。其中只有百分之一的行处于 pending 状态，便于观察选择性较高时的计划。

\set ON_ERROR_STOP on
BEGIN;
CREATE TEMP TABLE documents (id integer, payload jsonb NOT NULL);
INSERT INTO documents SELECT g, jsonb_build_object('status',
 CASE WHEN g%100=0 THEN 'pending' ELSE 'done' END)
FROM generate_series(1,10000) AS g;
CREATE INDEX documents_payload ON documents USING gin(payload);
ANALYZE documents;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF)
SELECT id FROM documents WHERE payload @> '{"status":"pending"}';
EXPLAIN (COSTS OFF)
SELECT id FROM documents WHERE payload->>'status'='pending';
CREATE INDEX documents_status ON documents ((payload->>'status'));
ANALYZE documents;
EXPLAIN (COSTS OFF)
SELECT id FROM documents WHERE payload->>'status'='pending';
SELECT value, value ? 'x' AS has_key,
 value->'x' IS NULL AS sql_null_json, value->>'x' IS NULL AS sql_null_text
FROM (VALUES ('{}'::jsonb),('{"x":null}'::jsonb),('{"x":"null"}'::jsonb)) v(value);
DO $$ BEGIN
 IF (SELECT count(*) FROM documents WHERE payload @> '{"status":"pending"}') <> 100 THEN
 RAISE EXCEPTION 'wrong containment count';
 END IF;
 IF '{"n":1}'::jsonb @> '{"n":"1"}'::jsonb THEN
 RAISE EXCEPTION 'number and string were conflated';
 END IF;
 IF '{"outer":{"x":1}}'::jsonb ? 'x' THEN
 RAISE EXCEPTION 'top-level existence searched recursively';
 END IF;
 IF ('{"x":null}'::jsonb->'x') IS NULL THEN
 RAISE EXCEPTION 'JSON null confused with missing key';
 END IF;
END $$;
ROLLBACK;

PostgreSQL 18.6 实测中，包含查询通过 documents_payload 使用位图索引扫描，返回一百行。文本提取条件最初使用顺序扫描，创建表达式索引后改用 documents_status。这些是当前分布下观察到的选择，并不是固定的计划承诺，也不能用来估计生产延迟。迁移到其他规模或数据形态后，需要重新检查实际计划。

最后三行分别展示缺失、显式 JSON null 和文本字符串。它们的存在标记依次为假、真、真；文本提取结果是否为 SQL NULL 的标记依次为真、真、假。断言还验证包含判断区分类型，键存在检查不会递归。修改查询形态时，应保留这些语义检查：只有结果仍符合预期，计划变快才有价值，不能用一个更快但混淆空值或类型的条件替代原有业务含义。

来源

PostgreSQL JSON 类型与索引，GIN 操作符类与表达式索引，已核验 2026-09-10。
PostgreSQL JSON 函数与操作符，提取、存在、包含和空值语义，已核验 2026-09-10。

Postgres 索引的存在意义就是回答问题

Tue, 20 Jul 2027 00:00:00 +0000

索引的价值在于改变真实查询需要完成的工作，索引了多少列并不是有效的成功指标。一个能直接找到某位客户最新三笔订单的窄 B-tree，可能胜过无法提供所需顺序的宽索引；读取几乎全部行的查询，则可能正确地忽略两者。评估时要把访问方式、排序和返回数据量放在一起，而不是看到索引名称就宣布优化完成。

从需要的结果出发

假设应用要查询某位客户最新三笔订单。customer 的等值条件缩小候选范围，placed_at 降序选择该客户最新记录，再用 id 作为最后决胜键，处理时间戳相同的情况。(customer, placed_at DESC, id DESC) 就表达了这条查询需要的键顺序。每个键都应对应可解释的条件或排序要求，而不是根据列名凭直觉添加。

收益不只是避免全表扫描。有序索引路径可以取得所需的有限结果后就停止，不必先收集该客户全部订单再排序。去掉 LIMIT，或改成返回大部分行后，成本平衡可能变化。因此同一个索引必须结合完整 SQL 和常用参数评价，不能只盯 WHERE 的一个片段，更不能把少量结果的计划当成大规模导出的保证。

WHERE 条件的文本顺序不会定义索引顺序。PostgreSQL 规划逻辑表达式，把 customer 等值写在 AND 前面或后面，不会重排 B-tree。真正相关的是索引方向、空值顺序、前导键限制和最终 ORDER BY。修改查询时应明确核对这些结构属性，而不是套用“列写在前面就能用索引”的笼统规则。

如实读取执行计划

EXPLAIN 展示计划工作，EXPLAIN ANALYZE 会真正执行并报告实际行数和循环次数。查询返回表中大部分数据，尤其需要索引中没有的宽列时，顺序扫描可能是正确选择。这不证明列顺序错误，也不证明索引创建失败。应把它看成优化器在当前条件下选择的访问成本，而不是必须消除的红色标记。

反过来，出现索引名也不证明查询便宜。索引扫描仍可能访问大量条目和堆元组，bitmap 路径可能还要排序，index-only 计划也可能检查堆可见性。结合 actual rows、适用时的 Heap Fetches、缓冲区活动和 Sort 阅读。顶层有 LIMIT 只有在下层也避免了大量多余工作时才真正省事，不能忽略 LIMIT 下面的完整树。

坏掉的样子

生产参数可能比开发参数多选出几千倍的行。小客户上表现优秀的索引，对拥有大量订单的大客户未必同样合算。数据分布、统计信息、缓存和并发都会影响计划与延迟，验证变更时应保留多个代表性参数。只测试一个常见编号，很容易遗漏真正拖慢系统的极端但合法客户。

索引还会持续产生存储、缓存、写入维护和构建成本。仅因为一次诊断查询返回 note，就把宽 note 加入热索引，可能让日常写入更贵。应该区分窄的高频应用查找和偶尔的大范围报表，要求每个附加键或 INCLUDE 列都有反复出现的真实用途。不能用读路径的一次局部收益掩盖整个系统长期承担的维护工作。

还有一种问题是分页依赖未定义的顺序。时间戳相同或执行计划改变时，如果 ORDER BY 没有给出确定选择，前几条记录可能变化。索引本身不会独立建立 API 的排序契约。顺序应明确写在 SQL 中，测试也应检查具体标识，而不只是检查“返回了三行”，否则拿错三行仍可能通过表面的数量校验。

快速验证

保存为 topn.sql，运行 psql -X -v ON_ERROR_STOP=1 -f topn.sql，连接可丢弃的 PostgreSQL 18 数据库。夹具创建两万笔订单，分布在一百位客户中，并加入一个较宽的 note 列用于比较全量查询。表和索引都是临时对象，最后回滚清理，不依赖业务数据。

\set ON_ERROR_STOP on
BEGIN;
CREATE TEMP TABLE orders (id integer, customer integer, placed_at integer, note text);
INSERT INTO orders SELECT g, g%100, g, repeat('x',100) FROM generate_series(1,20000) AS g;
CREATE INDEX orders_customer_recent ON orders (customer, placed_at DESC, id DESC);
ANALYZE orders;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF)
SELECT id,placed_at FROM orders WHERE customer=7 ORDER BY placed_at DESC,id DESC LIMIT 3;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF)
SELECT * FROM orders WHERE customer>=0;
SELECT array_agg(id ORDER BY placed_at DESC,id DESC) AS newest
FROM (SELECT id,placed_at FROM orders WHERE customer=7
 ORDER BY placed_at DESC,id DESC LIMIT 3) s;
DO $$ BEGIN
 IF (SELECT array_agg(id ORDER BY placed_at DESC,id DESC)
 FROM (SELECT id,placed_at FROM orders WHERE customer=7
 ORDER BY placed_at DESC,id DESC LIMIT 3) s)
 IS DISTINCT FROM ARRAY[19907,19807,19707] THEN
 RAISE EXCEPTION 'wrong newest orders';
 END IF;
END $$;
ROLLBACK;

客户七的结果按顺序是 19907,19807,19707。PostgreSQL 18.6 选择 Limit 加 index-only scan，找到三条匹配行后停止；因为新表尚未 VACUUM，仍需要堆可见性检查。查询所有客户并返回 note 时，计划选择顺序扫描，实际返回两万行。两种选择分别对应各自的任务，并不互相矛盾，也不说明某个索引突然失效。

断言检查确定的前三条结果，耗时和缓冲区数字不被写成固定预期。这个实验展示按工作负载使用索引，不提供跨机器速度倍数，也不保证生产数据与需求变化后同一计划永远最优。若未来增加全局排序、额外过滤或更多返回列，就应重新检查完整语句的访问路径和成本。

来源

PostgreSQL 多列索引，键条件与扫描范围，已核验 2026-09-10。
PostgreSQL 索引与 ORDER BY，有序读取与 LIMIT，已核验 2026-09-10。
PostgreSQL 使用 EXPLAIN，理解计划中的实际工作，已核验 2026-09-10。