SQL · XB 现场笔记

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

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

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

使用相邻的左闭右开范围

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

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

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

缺失范围是一种运维状态

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

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

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

坏掉的样子

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

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

是否允许空值，与范围选择是两回事。示例要求时间戳非空，避免缺失事件时间悄悄变成普通的例外数据。迁移后还应核对行数和标识；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 单用户 SQL 重跑接受九月的第一瞬间，以及测试中十月开始前的最后一个微秒；未测试客户端传输和并发迁移。没有相应目标时，十月一日被拒绝；创建 DEFAULT 后，这一行进入默认分区。随后尝试新增十月分区，因为匹配行仍留在 DEFAULT 中而失败，说明系统确实检查数据归属，并没有仅仅更新元信息。

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

来源

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

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

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，这也提醒读者区分排名输入与排名输出。

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

排名保留的是当前查询提供的行，不保证原始实体恰好一行。一对多连接可能在编号之前复制参赛者，导致同一实体占据多个位置。应先说明输入粒度并解决非预期的连接膨胀，再筛选前若干名。事后添加 DISTINCT 即使删掉重复输出，也不一定修复已经计算的名次；连接产生的行数本身就是排名语义的一部分。

坏掉的样子

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-10-15。
PostgreSQL 窗口教程，分区、排序和排名后的过滤，已核验 2026-10-15。

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 订单。匹配订单数量分别是二、一、零。十一和十二号订单虽然日期相同，但两行都能进入限额，因此这个夹具没有验证恰好跨过 LIMIT 边界时如何排除某条并列行；第三位客户验证没有匹配时是否仍然保留。断言检查具体标识和总行数，最后的回滚移除全部临时对象。

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

来源

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

分区把一张表拆成很多看起来还像一张的片段

Thu, 23 Dec 2027 00:00:00 +0000

声明式分区让 PostgreSQL 对外提供一张逻辑表，同时把行存放在不同分区中。父表负责写入路由，并作为统一查询入口；真正持有数据的是物理分区。它的主要收益往往来自生命周期管理和选择性访问，但选择分区时，也会影响键、查询形态和运维锁，不能只把它看作拆文件。

逻辑父表与物理子表

分区父表本身没有行存储。每个已挂载分区保存符合边界的行，可以有自己的存储参数、索引和维护活动。分区索引也类似，是各物理分区索引的集合，并不是在父表上再保存一整份相同数据。理解这一点，有助于区分统一入口与实际占用磁盘的关系。

范围、列表和哈希分区使用不同划分规则。应根据真实访问和保留要求选择键：按月保存事件可能适合范围分区，其他负载可能需要不同分布。声明式分区本身不会把这些分区自动分散到独立数据库服务器。本地分区仍共享所在数据库的资源和事务环境，不能因为表被拆开，就推断它已经实现分布式分片。

保持父表名字稳定，可以简化应用入口，但不能证明应用代码完全不用改。查询需要暴露适合的分区键限制，才可能从裁剪受益；主键与外键引用也可能需要重新设计。原本按全局唯一标识操作的调用，必须保留同样的身份语义，不能在物理拆分过程中悄悄改变其含义。

分区键不只影响路由

分区表上的唯一或主键约束必须包含全部分区键列，而且这些约束要求分区键不含表达式。各分区的独立索引，不能自行证明其他分区中不存在相同键。因此，day 与 id 的复合主键，并不保证 id 在不同日期之间仍然全局唯一。

从单表全局 id 主键迁移时，这个差别尤其重要。只是把日期加入主键，可能弱化原有身份契约。更改之前，应检查调用方、引用关系和重复防护要求。分区键不是可以完全脱离公开数据模型进行调整的纯物理参数，否则原来按 id 更新一行的操作，可能开始匹配多行。

修改分区键可以把行移动到另一个分区。目标分区必须存在并接受该行，索引和约束仍然生效。这是真实数据变更，不是免费的元数据修改。如果保留策略已经移除了目标范围，迟到的修正可能失败，即使逻辑父表仍然存在。生命周期设计应同时考虑正常新增和历史更正。

坏掉的样子

DETACH 把一张表从分区层级移除，但保留该表及其数据。通过父表查询时不再看到它，脱离后的关系仍可单独检查或导出。DROP 则会连同分区数据一起删除。脱离不等于删除，这两种操作也都不会自动生成已经验证过的归档或备份，不能因为维护命令成功就认定数据已妥善保留。

分区维护需要锁。普通 detach 需要父表上的强锁，可能等待长时间运行的操作，也会影响并发访问。PostgreSQL 提供锁行为不同的并发脱离形式，但有额外限制，例如不能放在显式事务块中执行，也不能用于包含 DEFAULT 分区的父表。并发脱离若被中断，还可能需要 FINALIZE 才能完成后续维护。应按照实际契约选择操作，不能把“元数据操作”理解为“一定不会阻塞”。

分区过多也会增加规划和内存成本，没有一个普遍适用的行数阈值能证明分区一定划算。应测量有代表性的读取和维护操作，在写入需要前创建未来分区，并明确迟到数据与保留策略如何配合。对于较小且索引合理的表，大量细碎分区可能只增加管理工作，而没有带来足够收益。

快速验证

把下面内容保存为 partition-lifecycle.sql，在可丢弃的 PostgreSQL 18 数据库中执行 psql -X -v ON_ERROR_STOP=1 -f partition-lifecycle.sql。实验使用临时分区和普通事务内 detach，最后回滚移除整个测试环境。

\set ON_ERROR_STOP on
BEGIN;
CREATE TEMP TABLE events (day date,id integer,PRIMARY KEY(day,id)) PARTITION BY RANGE(day);
CREATE TEMP TABLE events_sep PARTITION OF events FOR VALUES FROM ('2026-09-01') TO ('2026-10-01');
CREATE TEMP TABLE events_oct PARTITION OF events FOR VALUES FROM ('2026-10-01') TO ('2026-11-01');
INSERT INTO events VALUES ('2026-09-15',1),('2026-09-30',2),('2026-10-01',3);
SELECT id,day,tableoid::regclass AS physical_table FROM events ORDER BY id;
DO $$ BEGIN
 CREATE UNIQUE INDEX events_id_only ON events(id);
 RAISE EXCEPTION 'global id uniqueness accepted without partition key';
EXCEPTION WHEN feature_not_supported THEN RAISE NOTICE 'unique key must include partition key';
END $$;
SAVEPOINT id_scope;
INSERT INTO events VALUES ('2026-10-03',1);
SELECT id,day FROM events WHERE id=1 ORDER BY day;
ROLLBACK TO id_scope;
RELEASE id_scope;
UPDATE events SET day='2026-10-02' WHERE id=2;
SELECT id,day,tableoid::regclass AS physical_table FROM events ORDER BY id;
ALTER TABLE events DETACH PARTITION events_sep;
SELECT (SELECT count(*) FROM events) AS attached_rows,(SELECT count(*) FROM events_sep) AS detached_rows;
DO $$ BEGIN
 IF (SELECT array_agg(id ORDER BY id) FROM events) IS DISTINCT FROM ARRAY[2,3] OR
 (SELECT array_agg(id ORDER BY id) FROM events_sep) IS DISTINCT FROM ARRAY[1] THEN
 RAISE EXCEPTION 'detach changed stored rows';
 END IF;
END $$;
ROLLBACK;

本轮 PostgreSQL 18.6 单用户 SQL 重跑把标识一、二路由到九月，把标识三路由到十月；未测试客户端传输和并发脱离。数据库还拒绝在父表上只按 id 建立唯一索引。在保存点内，另一天的第二个 id 一可以按复合主键规则成功插入；回滚该保存点后，数据恢复到初始状态。这个结果直接展示复合唯一性与单列全局唯一性的差别。

修改标识二的日期后，tableoid 显示它已移动到十月。脱离九月分区后，父表可见两行，脱离的表仍保存一行。断言检查两侧确切的标识集合，证明 detach 改变的是成员关系，并没有丢弃存储数据。这里验证生命周期与键语义，没有测量生产锁持续时间，也不能替代完整的归档流程。

来源

PostgreSQL 表分区，物理存储、键、路由和分区管理，已核验 2026-10-15。
PostgreSQL ALTER TABLE，挂载、脱离行为与锁限制，已核验 2026-10-15。

公用表表达式把一个查询先命名再复用

Sun, 19 Dec 2027 00:00:00 +0000

公用表表达式在一条 SQL 内为查询结果命名。它可以先说明数据总体和中间计算，再写最终 SELECT，让复杂报表更容易阅读。这个名字不是持久表，也不自动承诺缓存结果、固定扫描次数或按顺序执行的一组命令。理解 CTE 时，应把可读结构与执行方式分别检查。

先确定作用域，再讨论执行

WITH 子句只属于当前语句。后续语句不能继续引用它的名字，执行结束后也没有一个可供建立索引或查询的 schema 对象。如果计算结果或查询定义需要保留到后续语句继续使用，应选择临时表、视图或其他合适的数据库对象。CTE 适合命名结果与语句作用域相匹配的工作，不能靠命名制造跨请求缓存。

现代 PostgreSQL 可以把非递归、没有 volatile 函数的 SELECT CTE 折叠进外层查询。默认情况下，只引用一次时会进行这种合并，使外层限制参与共同优化。因此，外层按主键查找时，条件可以直接作用于底层表的索引，而不必先生成独立中间结果再过滤。

同一个符合条件的 CTE 被引用多次时，PostgreSQL 默认通常会物化它。这能减少重复昂贵计算，但也可能阻止某个引用位置上的选择性条件被推入共享计算。这个区别从 PostgreSQL 十二开始适用；认为所有 WITH 都是固定优化边界，描述的是旧行为，不能覆盖当前默认规则。应根据实际版本和引用次数检查，而不是依赖旧经验。

物化是一项取舍

MATERIALIZED 请求独立计算。NOT MATERIALIZED 允许多次引用时也进行折叠，可能重复一部分工作，但让每次使用只访问自己需要的数据。对于递归或不是无副作用 SELECT 的 CTE，PostgreSQL 会忽略 NOT MATERIALIZED；它不会因此允许任意复制写入或 volatile 操作。

物化的 SELECT CTE 也不一定完整算到末尾。消费方可能只请求部分结果，不过排序、关联等操作又可能要求读取更多。物化同样不等于为后续语句建立一张带索引的可复用表。决定强制边界之前，应查看计划并测量真实负载，不能因为“物化”听起来像缓存就默认收益更好。

真正需要比较的是总工作量：多次选择性很高的索引查找，可能比构建并扫描大型共享结果便宜；重复昂贵计算又可能更慢。名字清楚与执行高效可以同时实现，但两者不能互相证明。业务条件应保持单一权威定义，执行控制则应在计划和测量支持时使用，而不是为猜想的性能问题增加边界。

坏掉的样子

修改数据的 CTE 使用不同规则。WITH 内的 INSERT、UPDATE、DELETE，以及 PostgreSQL 18 的 MERGE，即使输出没有被读取，也会执行一次并完成。可被引用的命名关系来自 RETURNING 输出，而不是修改后重新扫描目标表得到的结果。没有 RETURNING 的修改仍会发生，只是不能向后面的引用提供行。

修改子语句和主语句使用同一快照，实际修改顺序没有按文本从上到下依次执行的保证。后续部分需要变更后的行时，应通过 RETURNING 传递。不要在一条语句里尝试修改同一行两次，再期待文本位置决定最终结果。外层看起来只是 SELECT，也不能证明整条带 WITH 的语句只读；执行陌生查询时，必须检查内部是否有写操作。

快速验证

把下面内容保存为 cte.sql，在可丢弃的 PostgreSQL 18 数据库中执行 psql -X -v ON_ERROR_STOP=1 -f cte.sql。脚本先比较四个只读计划，再用 DELETE RETURNING 与 INSERT 搬移两条临时数据。末尾回滚会撤销实验中的修改并清除对象。

\set ON_ERROR_STOP on
BEGIN;
CREATE TEMP TABLE items (id integer PRIMARY KEY, value text);
INSERT INTO items SELECT g,'item-'||g FROM generate_series(1,10000) AS g;
ANALYZE items;
EXPLAIN (COSTS OFF)
WITH source AS (SELECT * FROM items) SELECT * FROM source WHERE id=7;
EXPLAIN (COSTS OFF)
WITH source AS MATERIALIZED (SELECT * FROM items) SELECT * FROM source WHERE id=7;
EXPLAIN (COSTS OFF)
WITH source AS (SELECT * FROM items)
SELECT a.id FROM source a JOIN source b USING(id) WHERE a.id=7;
EXPLAIN (COSTS OFF)
WITH source AS NOT MATERIALIZED (SELECT * FROM items)
SELECT a.id FROM source a JOIN source b USING(id) WHERE a.id=7;
CREATE TEMP TABLE moved (id integer,value text);
WITH removed AS (DELETE FROM items WHERE id<=2 RETURNING *)
INSERT INTO moved SELECT * FROM removed;
SELECT (SELECT count(*) FROM items) AS remaining,(SELECT count(*) FROM moved) AS moved;
DO $$ BEGIN
 IF (SELECT array_agg(id ORDER BY id) FROM moved) IS DISTINCT FROM ARRAY[1,2] THEN
 RAISE EXCEPTION 'RETURNING handoff failed';
 END IF;
 IF (SELECT count(*) FROM items) <> 9998 THEN RAISE EXCEPTION 'DELETE did not execute'; END IF;
END $$;
ROLLBACK;

PostgreSQL 18.6 中，默认单次引用的计划直接使用 items_pkey。显式 MATERIALIZED 增加 CTE Scan，其输入计划为顺序扫描；默认双次引用也共享一个物化 CTE，而 NOT MATERIALIZED 则形成两次基于索引的访问。这几条普通 EXPLAIN 只展示计划结构，没有测量执行时间，也不能据此宣称生产性能已经改善。

后面的修改语句确实执行了，items 剩余九千九百九十八行，moved 中有两行。断言确认转移的标识恰好是一和二，并确认原表对应行已删除。这里通过 RETURNING 在操作之间交接数据，不依赖目标表重读或文本顺序。减少外层消费量不能安全地阻止修改型 CTE 执行；类似实验应保留事务边界，并在执行前明确所有写入对象。

来源

PostgreSQL WITH 查询，折叠、物化和数据修改型 CTE，已核验 2026-10-15。
PostgreSQL SELECT 参考，WITH 作用域和 MATERIALIZED 控制，已核验 2026-10-15。

预备语句把取值与 SQL 结构分开

Sat, 16 Oct 2027 00:00:00 +0000

参数绑定为数据库中的取值提供一个明确位置。姓名里即使带有引号或分号，也仍然只是值，不会因此变成另一段查询条件。复用命名预备语句则是另一项优化：服务端能够在同一个会话内，跨多次执行保留语句信息。安全地绑定数据，并不要求应用为每一条查询都显式建立一个命名语句，也不要求先证明查询会频繁重复。

绑定保护 SQL 语法边界，却不会禁用取值内部仍需解释的语言。例如，绑定后的 LIKE 模式仍把百分号与下划线当成通配符。入口究竟接收模式，还是字面子串，需要另行约定，必要时按该运算符的规则转义。正则、全文检索和业务授权同样具有绑定之后的语义，不能因为成功参数化就认为输入已经符合全部产品约束。

坏掉的样子

在 Psycopg 中，占位符 %s 属于驱动接口，不是让程序使用 Python 字符串格式化。值应作为 execute 的第二个参数传入，占位符不要加引号，只有一个位置参数时也需要单元素元组。如果先把值插入字符串，再调用一个支持参数化的接口，原本希望保护的边界早就已经被越过；接口名称本身不会替程序补救这次拼接。

占位符代表值，不代表表名、列名或关键字。动态标识符需要明确的结构选择：先用白名单限制支持的列，再用驱动的标识符组合功能正确引用选中的列名。升降序关键字也应由应用控制。分页的数量与偏移量可以直接绑定，同时仍须按产品要求验证范围。能在语法上接收一个整数，不代表允许请求任意大的页面或无限制消耗资源。

预备语句不会把第一次的执行计划永久钉死。PostgreSQL 区分根据本次参数生成的定制计划，以及跨不同参数复用的通用计划；自动选择时会考虑规划开销与估算执行成本。模式或统计信息变化也可能触发重新规划。因此，语句保持参数化时，访问路径仍可以变化。是否复用某种计划，与输入能否变成 SQL 语法，是不同的性质，不能混为一谈。

快速验证

准备安装了 Psycopg 3 的 Python 环境，把 PG_DSN 设置为可丢弃的 PostgreSQL 数据库连接。连接配置沿用已有安全提供方式。实测版本为 Psycopg 3.3.5 与 PostgreSQL 18.6。将下面代码保存为 Python 文件，在已设置该环境变量的终端执行。使用的是临时表，连接关闭后会自动消失：

import os
import psycopg
from psycopg import sql

with psycopg.connect(os.environ['PG_DSN'], autocommit=True,
 prepare_threshold=5) as conn:
 conn.execute('CREATE TEMP TABLE people (id integer PRIMARY KEY, label text NOT NULL)')
 conn.execute("INSERT INTO people VALUES (1,'alice'),(2,'bob')")
 query = 'SELECT id FROM people WHERE label=%s ORDER BY id LIMIT %s'
 hostile = "' OR true --"
 assert conn.execute(query, (hostile, 10), prepare=False).fetchall() == []
 count = conn.execute('SELECT count(*) FROM pg_prepared_statements').fetchone()[0]
 assert count == 0
 print('bound without named preparation:', count, 'named statements; no match')
 for value in ("O'Reilly", r'a\b', 'x; DROP TABLE people; --'):
 assert conn.execute('SELECT %s::text', (value,), prepare=False).fetchone() == (value,)
 for label, expected in (('alice', [(1,)]), ('bob', [(2,)])):
 assert conn.execute(query, (label, 10), prepare=True).fetchall() == expected
 assert conn.execute('SELECT count(*) FROM pg_prepared_statements').fetchone() == (1,)
 print('named preparation reused: alice=1, bob=2')

 def ordered(column, limit):
 if column not in {'id', 'label'}:
 raise ValueError('unsupported sort column')
 if type(limit) is not int or not 1 <= limit <= 100:
 raise ValueError('limit must be an integer from 1 through 100')
 statement = sql.SQL('SELECT id FROM people ORDER BY {} LIMIT %s').format(
 sql.Identifier(column))
 return conn.execute(statement, (limit,), prepare=False).fetchall()

 assert ordered('label', 1) == [(1,)]
 for column, limit in [('label; DROP TABLE people', 1), ('id', 0), ('id', 101)]:
 try:
 ordered(column, limit)
 except ValueError:
 pass
 else:
 raise AssertionError('invalid request accepted')
 print('identifier allow-list and bound LIMIT checked')

 conn.execute('PREPARE plan_lab(text) AS SELECT id FROM people WHERE label=$1')
 conn.execute('SET plan_cache_mode=force_custom_plan')
 assert conn.execute("EXECUTE plan_lab('alice')").fetchall() == [(1,)]
 counters = "SELECT generic_plans,custom_plans FROM pg_prepared_statements WHERE name='plan_lab'"
 assert conn.execute(counters).fetchone() == (0, 1)
 conn.execute('SET plan_cache_mode=force_generic_plan')
 assert conn.execute("EXECUTE plan_lab('bob')").fetchall() == [(2,)]
 assert conn.execute(counters).fetchone() == (1, 1)
 print('same prepared statement: custom=1, generic=1')
 conn.execute('RESET plan_cache_mode')
 conn.execute('DEALLOCATE plan_lab')

第一项输出显示命名语句数量为零，而且看起来像注入的输入没有匹配任何记录。这次调用明确关闭命名预备，却保留参数绑定，证明安全边界在语句复用之前就存在。随后包含引号、反斜杠、分号的文本都原样返回，表仍可被后面的查询继续使用，字符串里写着删除命令也没有获得执行机会。

接下来两次显式预备调用复用了同一个命名语句，分别返回爱丽丝的编号一和鲍勃的编号二。连接的阈值配置允许显式预备。在本次驱动版本里，如果把 prepare_threshold 设为 None，命名预备整体被禁用，连显式请求也不会创建它。这个设置不等于关闭绑定，不能根据看不到命名语句就断言查询不安全。

排序函数对受支持的列和绑定上限返回一条结果；对不支持的列，以及一至一百之外的页大小，在发送 SQL 前拒绝。标识符引用负责保持语法正确，白名单负责说明这个入口究竟支持哪些合法结构。这两项职责不能交给任意请求文本决定，尤其不能以为加好了引号，就应该允许所有真实存在的列被外部选择。

最后，同一条 SQL 预备语句分别在强制定制计划与强制通用计划下执行。计数从通用零次、定制一次变成两种各一次，两次也都返回正确行。强制设置只是让差异能够稳定观察，并未测量自动模式面对真实倾斜数据会选择什么，更不是建议把整个服务永久改成某一种强制模式。退出前恢复设置并释放命名语句。

在真实部署中观察复用

PostgreSQL 默认的自动策略先用定制计划执行带参数语句，之后再比较通用方案。是否适合复用，需要结合真实参数分布和执行计划判断。这个只有两行数据的实验没有测量延迟，也没有统计协议往返次数；驱动如何批量发送协议消息、连接建立成本与查询本身开销，都会影响最终测量，不能从“预备”二字推导一个固定网络代价。

命名语句属于服务端会话，连接池和事务级代理必须正确处理这段生命周期。部署环境需要明确支持相应的预备语句行为，或者在不支持时关闭命名复用。即使只执行一次查询，也应默认绑定数据。租户过滤、对象授权和结果大小限制仍须单独成立：一条完全参数化的 SQL，也可能因为缺少业务权限条件而返回调用者无权查看的信息。

来源

Psycopg 参数接口，绑定语法与标识符组合，已核验 2026-10-15。
Psycopg 预备语句，阈值、显式预备和会话生命周期，已核验 2026-10-15。
PostgreSQL 18 PREPARE，定制计划、通用计划和自动选择，已核验 2026-10-15。
PostgreSQL 18 模式匹配，LIKE 通配符与转义语义，已核验 2026-10-15。

查询优化器在成本上押注

Fri, 17 Sep 2027 00:00:00 +0000

查询规划器根据预计工作量选择执行路径，并不会先把所有候选方案运行一遍、计时后再保留冠军。PostgreSQL 用统计信息和成本模型比较扫描、连接、排序等操作，因此选定的计划始终是建立在当前假设上的预测。诊断预测为何偏离实际，需要找出失效的具体假设，而不是把顺序扫描或嵌套循环当成天生有问题的节点。计划好不好，要放在完整查询的输入和输出要求中判断。

成本描述的是一个模型

PostgreSQL 的成本综合页面访问、元组处理、运算符计算等估计工作量，单位并不是毫秒。只需要拿到少量记录时，启动成本可能特别重要；必须产生完整结果时，总成本的意义更大。一个扫描如果已经提供了后面需要的顺序，就可能省掉排序，因此单独看来最便宜的扫描，不一定是整条查询最合适的输入。只比较一个节点会漏掉它给后续处理带来的影响。

规划搜索也有边界。数据库会考虑不同路径和连接顺序，而不是实际执行全部候选。连接关系很多时，PostgreSQL 可以启用遗传查询优化器来控制规划开销。可用索引、合法变换、配置与搜索选择共同限制了候选集合，所以不能把最后的选择描述为“对所有想象得到的实现都保证数学最优”。这种边界并不表示规划器不可信，只是说明它需要接受真实测量的检验。

坏掉的样子

统计刚刷新也可能估错。普通统计分别描述每一列，在组合两个过滤条件时可能假设它们相互独立，而实际两列总是一起变化。中间结果被低估后，反复查找看起来就比实际便宜，后续连接顺序也可能受到影响。如果模型本身没有表达这两列的关系，重复运行相同的分析不会凭空补上这部分知识。统计陈旧与统计种类不足，不能混成一种诊断。

扩展统计也只解决特定问题。函数依赖可以帮助估计与常量比较且彼此兼容的等值条件，但它不保存具体值之间的完整对应关系，也不是范围条件或任意跨列比较的一般证明。即使已经收集到很强的依赖，一组实际上互不兼容的常量仍可能被严重高估。因此验证中既需要兼容的正向情况，也需要一个不成立的组合来展示限制。

快速验证

在 PostgreSQL 18 的 psql 中执行下面的临时表实验。两列始终保存相同的值，一共有一百种不同值，每种重复一百次。所有修改都放在事务中，最后回滚会一并移除表和相应统计对象。

\set ON_ERROR_STOP on
BEGIN;
CREATE TEMP TABLE dimensions (a integer,b integer);
INSERT INTO dimensions SELECT g%100,g%100 FROM generate_series(1,10000) AS g;
ANALYZE dimensions;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF) SELECT * FROM dimensions WHERE a=7 AND b=7;
CREATE STATISTICS pg_temp.dimensions_dependency (dependencies) ON a,b FROM dimensions;
ANALYZE dimensions;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF) SELECT * FROM dimensions WHERE a=7 AND b=7;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF) SELECT * FROM dimensions WHERE a=7 AND b=8;
DO $$ BEGIN
 IF (SELECT count(*) FROM dimensions WHERE a=7 AND b=7) <> 100 OR
 (SELECT count(*) FROM dimensions WHERE a=7 AND b=8) <> 0 THEN RAISE EXCEPTION 'wrong correlated population'; END IF;
END $$;
ROLLBACK;

在建立扩展统计之前，PostgreSQL 18.6 对 a=7 AND b=7 估计一行，实际返回一百行。两个条件单独都选中百分之一的数据；把选择率相乘，就得到一万行中的万分之一，也就是一行。这套算术在条件独立时有意义，而夹具故意让两列完全相关，所以假设与数据并不相符。

创建函数依赖对象，告诉下一次 ANALYZE 要收集哪组列之间的关系。第二份计划估计一百行，实际也返回一百行。仅仅创建统计对象还没有填入所需信息，后续分析这一步不能省略。扫描仍然是顺序扫描，因为本例没有任何索引，仍要检查这张小表的全部内容。这里证明的是行数预测改善，不能由此声称应用已经变快，更不能把节点没有变化当成实验失败。

最后一个条件改成 a=7 AND b=8。查询实际返回零行，但函数依赖给出的估计仍是一百行。这个负向案例说明：知道一列决定另一列，并不等于这种统计知道“七只能对应七”这一条具体映射。末尾断言分别核对兼容与不兼容条件的正确结果。估计失真影响规划选择，却不会把本来不符合条件的记录变成合法查询结果。

根据偏差选择下一次实验

如果缺少的是常见值组合的信息，多列常见值列表能够表达这些组合。其他负载可能需要不同类型的统计、恰当的索引，或者让可索引条件更清晰的表达式改写。应当根据真实过滤条件增加对象，而不是为所有列组合都预先配置扩展统计；收集和使用不必要的统计也会消耗分析与规划资源。

比较替代方案时，固定数据集、参数、相关设置和结果要求，同时观察处理行数、缓冲区访问、内存溢写与实际延迟。局部节点便宜，却把更多工作推给上层，不能算整个查询改善。反过来，即使估计行数准确，也没有排除等待、昂贵读写或成本模型不适合当前环境的可能。应沿预计工作与实际工作之间的具体差异继续验证，再决定是否调整全局规划参数。

来源

PostgreSQL 18：规划器与优化器，候选访问路径与连接策略，已核验 2026-09-10。
PostgreSQL 18：规划器统计，列分布与扩展统计的限制，已核验 2026-09-10。
PostgreSQL 18：多变量统计示例，相关条件与函数依赖估算，已核验 2026-09-10。

组合索引贴合多列的查询

Wed, 15 Sep 2027 00:00:00 +0000

复合 B-tree 索引先按第一个键排序，再在第一个键相同的组内按下一个键排序。这种元组顺序可以让“某个租户的一段时间”很容易定位。应理解的是条件能缩小多少索引扫描范围，而不是禁止查询后面的列，也不是要求 WHERE 中的条件必须按建索引的顺序书写。这几个概念混在一起，会导致错误的索引设计。

排序的是键，不是 SQL 条件

对于 (tenant, happened) 索引，tenant 等值条件加 happened 范围条件描述了树中的一小段。PostgreSQL 可以定位这一段，而不用检查所有租户。即使把时间条件写在 WHERE 的前面、租户条件写在后面，逻辑上的合取关系也没有改变。数据库定义中的键顺序与查询文本的书写顺序，是两件不同的事情，不能拿文本位置判断索引是否可用。

通常，前导列的等值条件和第一个非等值键上的范围条件，决定必须扫描的区间。更后面的键条件仍可在索引中检查，即使不能继续缩小一个简单连续区间，也可能减少访问堆表的次数。调换索引键会改变这些机会，但不意味着某种排列在所有查询中都完全无用。需要结合查询实际要求的范围和返回列判断。

后面的键仍可能有用

PostgreSQL 18 在合适时可以使用 B-tree skip scan：如果遍历缺少等值条件的前导键取值，并在每组内重新搜索，比读取大部分索引更便宜，就可能采用这种路径。只有少数几个租户时，仅过滤 happened 也可能通过各租户分组完成查找；前导键不同值很多时，这种重复搜索可能太贵，规划器便可能选择顺序扫描或其他索引。

即使没有合算的 skip scan，某些只涉及后面键的条件仍可能扫描复合索引。问题是成本、覆盖范围与选择性，不是 SQL 是否合法，也不是索引必然被忽略。不能把“最左前缀”这种便于记忆的说法扩展成绝对禁令，尤其在目标数据库明确支持其他访问路径时。版本和真实计划必须优先于口号。

把排序和工作负载一起考虑

固定 tenant 后，后面的 happened 顺序可以支持该租户的时间排序。但跨多个租户时，索引先按租户分组，不会直接提供全局时间顺序。Bitmap 扫描也不保留索引顺序，仍可能需要单独排序。因此应看完整计划，而不是看到索引包含排序列就断言不会发生 Sort。LIMIT 对尽快返回前几行的需求也会改变最合适的路径。

“等值列在前、范围列在后”是一个查询形状的起点，并不是“永远把选择性最高的列放第一”的统一算法。多个查询共享的前缀、连接、排序方向、参数分布和写入成本都会影响选择。比较真正反复出现的查询，再保留必要的最小索引集合。重复且宽大的索引即使没有读者，也会占用缓存和写入维护资源。

坏掉的样子

团队可能为租户内查询建立 (tenant, happened)，随后增加全局时间线，却假定两者效率相同。新查询的顺序要求和过滤范围已经不同，需要重新评估。另一种回归来自测试参数：一个小租户的计划很好，不代表拥有大部分行的租户也同样便宜。同一条参数化 SQL 面对不同数据分布，成本可能差很多，统计信息和代表性参数比单次截图更可靠。

错误规则也会带来不必要的索引变更。因为“原索引绝不可能查后列”而为每个后缀新增索引，可能重复已有能力；反过来，相信 skip scan 总能补救缺失前缀，又可能掩盖昂贵路径。修改数据库结构前，应检查实际行数、缓冲区、排序与访问方式，说明哪个真实查询获得了什么改善。

快速验证

把代码保存为 composite.sql，用 psql -X -v ON_ERROR_STOP=1 -f composite.sql 连接可丢弃的 PostgreSQL 18 数据库。临时夹具包含四个租户取值和两万个事件编号，最后回滚删除全部实验对象，不依赖已有表或数据。

\set ON_ERROR_STOP on
BEGIN;
CREATE TEMP TABLE events (tenant integer, happened integer, body text);
INSERT INTO events SELECT g % 4, g, repeat('x',40) FROM generate_series(1,20000) AS g;
CREATE INDEX events_tenant_time ON events (tenant, happened);
ANALYZE events;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF)
SELECT happened FROM events WHERE tenant=2 AND happened BETWEEN 100 AND 120
ORDER BY happened;
SELECT array_agg(happened ORDER BY happened) AS matching_times
FROM events WHERE happened BETWEEN 100 AND 120 AND tenant=2;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF)
SELECT tenant FROM events WHERE happened=12346;
DO $$ BEGIN
 IF (SELECT array_agg(happened ORDER BY happened) FROM events
 WHERE happened BETWEEN 100 AND 120 AND tenant=2)
 IS DISTINCT FROM ARRAY[102,106,110,114,118] THEN
 RAISE EXCEPTION 'wrong composite range';
 END IF;
 IF (SELECT tenant FROM events WHERE happened=12346) IS DISTINCT FROM 2 THEN
 RAISE EXCEPTION 'suffix predicate lost the row';
 END IF;
END $$;
ROLLBACK;

租户范围查询精确返回 102,106,110,114,118，把 WHERE 条件反过来书写时结果相同。在 PostgreSQL 18.6 上，它使用 bitmap index scan 后再排序；仅按后列查询的语句通过带重复索引搜索的 index-only scan 返回租户二，直接证明没有 tenant 等值条件也存在可用路径。两种计划不同，但都符合各自的逻辑结果。

具体计划名称、缓冲区计数和搜索次数是这份数据上的观测，不是任何配置下都必须出现的常量。断言验证结果语义，性能判断还应增加前导键的不同取值数量，测量后列访问在真实分布下是否仍值得使用。这样才能把“索引可以参与”与“该索引在这个负载下划算”分开。

来源

PostgreSQL 多列索引，前导条件和 skip scan，已核验 2026-09-10。
PostgreSQL 索引与 ORDER BY，有序扫描与排序选择，已核验 2026-09-10。

EXPLAIN 让你看清 Postgres 会怎么做

Thu, 08 Jul 2027 00:00:00 +0000

EXPLAIN 打印规划器准备采用的执行计划与代价；EXPLAIN ANALYZE 则真的跑一遍语句，把估算变成测到的行数与时间。它们回答的是两个不同问题：规划器认为应该怎样做，以及数据库实际怎样做。排障时先看前者理解意图，再用后者测量现实，别把 cost 当成秒数，也别在生产库上无准备地执行一条会写数据的 ANALYZE。

计划提供需要核对的估计与观测，而不是单凭行数差异就能完成的诊断。循环次数和提前停止也会制造表面差距；估计准确时，查询仍可能受到锁等待、溢写或大量必要工作的影响。它告诉你读了哪些表、用了什么索引、预计经过多少行，以及每个节点把多少工作交给下一个节点。把计划保存进工单，和请求参数、统计信息更新时间、数据库版本一起记录，几周后的回归才有可比基线。只贴一句“慢”没有证据；保存计划能帮助定位值得检验的假设，但不能自动解释所有请求延迟。

自上而下读形状

文本计划先打印父节点，再缩进打印它的子节点。向下读可以理解节点依赖哪些输入，向上看可以理解结果怎样汇合。执行可能按需发生：上层的 LIMIT 得到足够多的行便会停止索取，下层排序却可能需要读完全部输入才能交出第一行。缩进描述依赖关系，并不是所有节点通用的执行时间顺序。

cost 使用规划器的工作量单位，不是毫秒。父节点总成本包含子节点，不能把整棵树的数字直接求和。启动成本表示返回第一行前预计投入多少工作，总成本表示完成节点的估算。实际时间和实际行数在 loops 大于一时按每次执行取平均；判断重复工作要结合循环次数，同时避免把父节点包含的子节点时间再加一次。

阅读时先问三个问题。第一，计划是否走了预期的访问路径，例如选择性很高的条件是否用了索引。第二，估算行数和实际行数是否在同一个数量级，数量级错了通常比单个节点的 cost 更值得处理。第三，数据流在哪里膨胀或等待，宽大的中间结果会把后面的排序、连接和聚合一起拖慢。沿着这三个问题读，计划就从一堆术语变成了可验证的因果链。

追踪工作量与放大点

行数最多只是线索，不能直接证明瓶颈。连续读取的大表扫描可能比随机访问索引更便宜，一个每次很快却反复执行数万次的节点也可能主导延迟。先找估算与实际第一次发生明显偏离的地方，再追踪它怎样影响后续连接、排序与内存。嵌套循环并非天然错误：外表很小、内表有匹配索引时它可能最快；危险的是外表被严重低估后仍反复访问内表。

把计划格式化为 JSON 可以让工具比较节点，手工排障先用普通 EXPLAIN 确认访问路径，再按需执行带 ANALYZE、BUFFERS 的测量。缓冲命中、缓冲读取、临时文件读写能帮助定位数据访问与排序落盘。缓冲读取不等于真实磁盘读取，因为操作系统缓存也可能提供数据；看到 read 就宣布磁盘慢，证据还不够。VERBOSE 会显示更多输出列和别名，适合定位复杂视图。

用 ANALYZE 让行数和代价对齐

EXPLAIN ANALYZE 会真实执行查询，同时给出估算与实际行数、节点耗时和循环次数。两者出入很大，可能来自统计过时、分布倾斜或列间相关性；重新收集统计有时能改善，但不能保证修好所有偏差。写入实验放到隔离数据库，并设置语句超时。事务回滚只能撤销可回滚的数据库改动，不能撤销已经分配的序列值、函数或触发器对外部系统造成的不可回滚副作用。SELECT 也可能调用带副作用的函数，不能只根据语句开头判断安全。

可以按需提高相关列的统计目标，或者建立描述同一张表中相关列的扩展统计，但这些动作也要由测量验证。扩展统计不能修复所有估计，目前也不是跨表连接选择性的通用信息来源；应先确认它改变了真正有问题的估计，再归因于统计改进。索引收益仍要根据整个查询的工作量评估。若同一语句对小租户很快、对大租户很慢，要用应用实际的预备语句路径比较通用计划和定制计划。PostgreSQL 核心并没有通用的 SQL 提示语法，不要凭空加入提示来强行选择节点。每次只改变一个变量，把结果集、计划和延迟并排保存。

坏掉的样子

第一种失败是调错了查询。一个页面发出五条语句，工程师给最熟悉的那一条加索引，用户延迟却没有变化，因为真正耗时的是另一个查询。可以按 pg_stat_statements 的累计执行时间筛选候选，再关联具体慢请求；累计耗时很高也可能只是调用频繁，不能单凭这个排名解释某次请求的尾延迟。应结合调用次数、参数和请求追踪，避免让熟悉程度代替耗时证据。估算行数远小于实际行数时，再沿循环次数和数据流找放大点，而不是先全局禁用某种连接算法。

另一个故障是把 EXPLAIN ANALYZE 当成无副作用的测速命令。有人在主库直接跑大批量更新，结果测试本身锁住业务、写入 WAL，还触发了通知或审计。修法是先复制语句到隔离副本，读查询用 BEGIN 和超时保护，写查询先用普通 EXPLAIN 估算，再用生产级回放数据测量。计划采集也要脱敏参数，避免把客户信息带进日志或工单。

另一种常见失败是参数敏感性被平均值掩盖。某个租户占了大多数数据，其他租户很小，共用的预备语句通用计划却无法同时照顾两种分布。用两个有代表性的参数分别保存计划，再检查统计、查询形状和实际执行路径。每个优化动作都应对应结果不变及资源消耗改善的证据，否则只是换了一段计划文本。

快速验证

在允许写入的临时实验数据库执行下面的事务。数据表属于当前会话，结束时回滚清理，不依赖已有订单或客户表：

BEGIN;
SET LOCAL statement_timeout = '10s';
CREATE TEMP TABLE explain_demo AS
SELECT n AS id, n % 100 AS tenant_id FROM generate_series(1, 20000) AS g(n);
ANALYZE explain_demo;
EXPLAIN (ANALYZE, BUFFERS)
SELECT id FROM explain_demo WHERE tenant_id = 17 ORDER BY id LIMIT 10;
SELECT id FROM explain_demo WHERE tenant_id = 17 ORDER BY id LIMIT 10;
CREATE INDEX explain_demo_lookup ON explain_demo (tenant_id, id);
EXPLAIN (ANALYZE, BUFFERS)
SELECT id FROM explain_demo WHERE tenant_id = 17 ORDER BY id LIMIT 10;
SELECT id FROM explain_demo WHERE tenant_id = 17 ORDER BY id LIMIT 10;
ROLLBACK;

两次普通 SELECT 都应返回从 17 到 917、间隔一百的十个编号。比较两份计划中的扫描类型、排序节点、过滤行数与缓冲访问；第二份通常会利用有序索引。不同版本和环境的精确节点形状与耗时可以不同，不要把某个毫秒数字写成硬性断言。回滚后实验对象消失；迁移到真实业务前，还需用接近生产分布的数据重复测量，并确认其他重要查询没有回退。

来源

PostgreSQL EXPLAIN 文档，EXPLAIN 选项与真实执行的副作用，已核验 2026-10-15。
PostgreSQL 使用 EXPLAIN，说明计划节点、估算行数与 ANALYZE 输出，已核验 2026-10-15。
PostgreSQL 18: Extended statistics，同表列相关性及 ANALYZE 采集，已核验 2026-10-15。
PostgreSQL 18: CREATE STATISTICS，统计种类与表连接选择率估算的限制，已核验 2026-10-15。
PostgreSQL 18: pg_stat_statements，调用次数与累计执行时间，已核验 2026-10-15。

查询参数守住取值与 SQL 的边界

Mon, 17 May 2027 00:00:00 +0000

参数化查询通过不同的接口参数传递数据库指令与实际取值。数据库把指令解释为 SQL，再把各个参数用于需要值的位置。这种边界既适用于 SQLite 这样的嵌入式引擎，也适用于客户端连接服务端的数据库；它不依赖一次网络交互，更不要求应用显式管理命名的服务端语句。重点在真实调用如何传值，而不是有没有某个名为“预编译”的包装函数。

坏掉的样子

字符串拼接会拆掉这条边界。姓名中的一个引号可能提前结束原本的字面量，后面的文本就有机会变成条件或注释。仅仅禁用分号无法修复问题，因为攻击者可以在不追加第二条语句的情况下，改变同一条查询的含义。同样，一个接口即使拒绝一次执行多条语句，也仍然需要正确绑定参数，不能把这个限制当作注入防护已经完成的证据。

绑定可以防止值变成 SQL 语法，但所选运算符仍会按自身规则解释这个值。对于 LIKE，百分号匹配一段字符，下划线匹配一个字符。因此，一个经过绑定的搜索串，仍可能比用户期望的普通文本搜索匹配更多记录。这属于模式语义的问题，不说明绑定失效，却说明“输入不会执行成 SQL”还不等于“搜索符合产品要求”。

另外一些错误也不会造成注入，却会给出错误结果。把逗号分隔的文本交给一个 IN 占位符，它仍是一个标量，不会自动展开成列表。把列名当作值绑定，得到的仍是文本，不是列引用。因此，类型检查、允许的查询结构与业务权限，都需要在绑定之外独立成立。

快速验证

直接运行下面的完整 Python 脚本，只需要标准库 sqlite3。它创建内存数据库作为样本，完成断言后关闭连接。记录中的运行环境为 Python 3.12.14 与 SQLite 3.53.1。故意保留的脆弱查询仅用于比较三个虚构用户的结果，不连接任何真实业务数据：

import sqlite3

with sqlite3.connect(':memory:') as db:
 db.execute('CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT NOT NULL)')
 db.executemany('INSERT INTO users VALUES (?, ?)', [(1, 'Alice'), (2, 'A_1'), (3, 'Ab1')])
 payload = "' OR 1=1 --"
 # Deliberately vulnerable comparison, only against this in-memory fixture.
 unsafe = "SELECT id FROM users WHERE name='" + payload + "' ORDER BY id"
 assert sorted(db.execute(unsafe).fetchall()) == [(1,), (2,), (3,)]
 assert db.execute('SELECT id FROM users WHERE name=?', (payload,)).fetchall() == []
 print('concatenated: 3 rows; bound: 0 rows')
 for value in ("O'Reilly", r'a\b', 'x; DROP TABLE users; --'):
 assert db.execute('SELECT ?', (value,)).fetchone() == (value,)
 assert db.execute('SELECT count(*) FROM users').fetchone() == (3,)
 print('quote, backslash, semicolon: literal round trips')
 assert db.execute('SELECT id FROM users WHERE name LIKE ? ORDER BY id', ('A_1',)).fetchall() == [(2,), (3,)]
 literal = 'A_1'
 escaped = literal.replace('!', '!!').replace('%', '!%').replace('_', '!_')
 assert db.execute("SELECT id FROM users WHERE name LIKE ? ESCAPE '!' ORDER BY id", (escaped,)).fetchall() == [(2,)]
 assert db.execute('SELECT id FROM users WHERE name=?', (literal,)).fetchall() == [(2,)]
 print('bound LIKE: 2 rows; escaped LIKE and equality: 1 row')
 assert db.execute('SELECT id FROM users WHERE id IN (?)', ('1,3',)).fetchall() == []
 assert db.execute('SELECT id FROM users WHERE id IN (?,?) ORDER BY id', (1, 3)).fetchall() == [(1,), (3,)]
 assert db.execute('SELECT ? FROM users LIMIT 1', ('name',)).fetchone() == ('name',)
 assert db.execute('SELECT id FROM users ORDER BY id LIMIT ? OFFSET ?', (1, 1)).fetchall() == [(2,)]
 assert db.execute('SELECT id FROM users ORDER BY id LIMIT ?', (-1,)).fetchall() == [(1,), (2,), (3,)]
 assert db.execute('SELECT id FROM users ORDER BY id LIMIT ?', (0,)).fetchall() == []
 print('IN needs separate values; bound column is a literal; LIMIT/OFFSET bind')
 print('negative LIMIT removes the cap; zero LIMIT returns no rows')
db.close()

拼接查询返回三个编号，绑定查询面对相同输入则没有任何匹配。恶意输入中的注释还会删掉原先追加的排序部分，因此断言先对脆弱查询的结果排序，再比较编号集合；实验没有依赖未声明顺序的查询恰巧按插入顺序返回。这也展示了注入会改变原指令的多个部分，不只是多匹配一行那么简单。

接下来的断言确认引号、反斜杠和带有分号的字符串全部原样往返，表中记录数仍为三。这些检查真正调用了 SQLite 驱动，并非模拟字符串转义，也不是看查询文本中有没有问号。审阅真实调用点时，应把 SQL 文本与参数传入方式一起看，不能只审一个看似安全的查询模板，却忽略调用方已经提前拼接了值。

绑定后的模式 A_1 同时匹配名字 A_1 和 Ab1。指定感叹号作为转义字符并转义下划线后，结果才缩小到原样名字。如果搜索文本本身可能包含感叹号，必须先转义这个转义字符，再处理百分号和下划线。若需求只是完全相等匹配，直接使用等号更简单，在本例中也只返回那个原样名字，没有必要先引入模式语义再尝试消除它。

单个参数中的 1,3 没有匹配任何编号；两个占位符分别绑定两个整数，才返回编号一和三。后一个查询返回字面文本 name，说明值占位符不能用来选择某列。最后，数量和偏移量都采用数字绑定，返回编号二。分页不需要把数字先转换为字符串再拼进 SQL。SQLite 的 LIMIT 绑定负一会取消数量上限，绑定零则不返回记录；新增断言展示了，即便语法传参安全，应用仍需独立规定页大小范围，不能把已绑定整数直接当成资源限制已经成立。

检查完整数据路径

占位符必须符合实际驱动接口。Python 的 SQLite 接口支持问号与命名参数，Psycopg 则使用另一套记法。参数集合应独立传入，不应先做宿主语言的格式化。即使某个值来自自己的数据库，再次用于查询时也仍是数据；它曾经被存储过，并不能使下一次把它拼进 SQL 的操作自动安全。持久化来源不是语法信任标记。

对于长度变化的列表，只构造必要的占位符结构，再逐项绑定；驱动提供受支持的集合能力时，可按其文档使用。同时定义空列表语义，并遵守参数数量上限。动态标识符和排序关键字需要在允许的查询结构中选择；对任意 SQL 文本删掉几个标点，并不能可靠替代这项选择，也可能改变合法输入的含义。

即使所有值都已绑定，仍应限制页大小，并按对象检查权限。参数化保护的是 SQL 语法边界，不是整个业务操作。验证应同时覆盖正常返回、看起来像攻击的字符串以及所用运算符的特殊输入，避免一次安全改写悄悄扩大搜索范围、改变排序，或者因为原本就缺少权限条件而继续暴露其他用户的记录。

来源

SQLite SELECT，负数与零 LIMIT 的行为，已核验 2026-10-15。
Python sqlite3，驱动占位符与参数绑定接口，已核验 2026-09-12。
SQLite 表达式，参数、LIKE 转义与 IN 语义，已核验 2026-09-12。
OWASP SQL 注入防护，参数化取值与允许的结构选择，已核验 2026-09-12。

INSERT ... ON CONFLICT 把竞态收进一条语句

Thu, 25 Mar 2027 00:00:00 +0000

INSERT … ON CONFLICT 让 PostgreSQL 在真正写入的语句内部处理插入冲突。它用明确的冲突策略和实际索引或约束，替代脆弱的“先查键是否存在，再决定插入”流程。但它不会把所有插入错误都变成更新成功，也不会替应用决定新旧数据应该如何合并。使用前，需要先确定唯一键和业务动作。

冲突目标定义处理范围

(name) 这样的目标，要求 PostgreSQL 推断匹配的唯一索引。表上必须实际存在适用的唯一性规则；写出 ON CONFLICT 并不会自动建立约束。如果键涉及表达式或部分索引，索引表达式和谓词也会影响匹配。目标没有匹配到索引时会报错，而不是悄悄改用另一种插入策略。可空业务键尤其需要注意：普通唯一索引把空值视为彼此不同，多次写入空键不一定冲突。若业务要求这些行相互冲突，应选择非空键，或明确采用符合需求的 NULLS NOT DISTINCT 语义。

DO UPDATE 必须指定目标，其裁决依据只能是受支持的非延迟唯一约束或唯一索引，排除约束不能作为 DO UPDATE 的冲突裁决依据。DO NOTHING 的处理范围更广，包括受支持的排除约束，也可以省略目标来处理适用的冲突规则。但这些能力都不会让外键、非空或检查约束失效，不能把它当成通用的错误忽略机制。

原子的插入或更新行为，解决的是并发争用同一键时的协调。语句仍可能等待其他事务持有的相关行或索引冲突，正常的事务错误也仍可能发生。原子性描述结果如何被协调，不保证完全无锁、不阻塞，也不意味着调用方永远不用处理事务级重试。

明确写出合并规则

目标表名或别名代表已有行，EXCLUDED 代表原本准备插入的行，其中也反映 BEFORE INSERT 触发器的相关影响。赋值为 EXCLUDED.total 是替换旧值；赋值为已有 total 加 EXCLUDED.total 是累加一次贡献。虽然语法相近，两者回答的业务问题不同，不能把其中一种默认当成“正确的 upsert”。

计数器直接在更新表达式中使用已有行，可以避免客户端先读旧值，再算一个可能过时的替换值。带版本的文档则可以用 WHERE 拒绝较旧版本。这个条件在找到并锁定冲突行后求值，因此，即使最终没有更新，它也可能与其他写入者争用锁。条件跳过不等于完全没有执行成本或并发影响。

RETURNING 只输出真正被插入或更新的行。DO NOTHING 不会返回已经存在的那条记录；DO UPDATE 的 WHERE 为假时，也不会返回行。所以空结果不能唯一推断出“走了 DO NOTHING”，更不能直接认定数据库中没有该记录。调用方应明确如何解释被跳过的写入，而不是把所有零行返回都当成同一种错误。

坏掉的样子

一个批次中可能有两条输入使用相同冲突键。DO UPDATE 不允许同一条语句对同一既有行更新两次，遇到这种情况会抛出基数错误。提交前应按业务规则合并或拒绝重复输入。随便保留最后一条，可能把原来的累加操作静默改成替换，也可能丢掉本来应该合计的贡献。

ON CONFLICT 也不自动提供幂等性。一次累加请求的响应不确定时，重试可能再次加上同一份数值。如果一个逻辑请求只能生效一次，需要另有明确的请求身份与唯一性契约。类似地，无条件替换也可能在旧请求晚到时覆盖较新的状态；原子执行不能替代版本或顺序规则。

其他约束错误仍然重要。键冲突不代表新数据中的非法值可以忽略，PostgreSQL 可能在执行 DO NOTHING 之前就拒绝 CHECK 违规。序列默认值也可能在冲突处理前求值，所以被跳过的插入仍可能消耗编号。这两种行为都不说明冲突处理器失效，只是说明它的处理范围并不覆盖整个写入生命周期。

快速验证

把下面内容保存为 upsert.sql，在可丢弃的 PostgreSQL 18 数据库中执行 psql -X -v ON_ERROR_STOP=1 -f upsert.sql。临时计数表只存在于实验事务中，末尾回滚会清除全部测试数据。

\set ON_ERROR_STOP on
BEGIN;
CREATE TEMP TABLE tally (
 name text PRIMARY KEY,total integer NOT NULL CHECK (total>=0),version integer NOT NULL
);
INSERT INTO tally VALUES ('jobs',5,1) RETURNING *;
INSERT INTO tally VALUES ('jobs',3,2)
ON CONFLICT (name) DO UPDATE
SET total=tally.total+EXCLUDED.total,version=EXCLUDED.version
RETURNING *;
WITH changed AS (
 INSERT INTO tally VALUES ('jobs',100,3) ON CONFLICT (name) DO NOTHING RETURNING *
) SELECT count(*) AS do_nothing_returned FROM changed;
WITH changed AS (
 INSERT INTO tally VALUES ('jobs',100,1)
 ON CONFLICT (name) DO UPDATE SET total=EXCLUDED.total,version=EXCLUDED.version
 WHERE tally.version<EXCLUDED.version RETURNING *
) SELECT count(*) AS stale_update_returned FROM changed;
DO $$ BEGIN
 INSERT INTO tally VALUES ('jobs',-1,4) ON CONFLICT (name) DO NOTHING;
 RAISE EXCEPTION 'check violation was swallowed';
EXCEPTION WHEN check_violation THEN RAISE NOTICE 'CHECK still rejects invalid input';
END $$;
DO $$ BEGIN
 INSERT INTO tally VALUES ('jobs',1,4),('jobs',2,5)
 ON CONFLICT (name) DO UPDATE SET total=EXCLUDED.total;
 RAISE EXCEPTION 'same row updated twice';
EXCEPTION WHEN cardinality_violation THEN RAISE NOTICE 'duplicate input keys rejected for DO UPDATE';
END $$;
SELECT * FROM tally;
DO $$ BEGIN
 IF (SELECT total FROM tally WHERE name='jobs') IS DISTINCT FROM 8 OR
 (SELECT version FROM tally WHERE name='jobs') IS DISTINCT FROM 2 THEN
 RAISE EXCEPTION 'conflict action changed the wrong state';
 END IF;
END $$;
ROLLBACK;

本轮 PostgreSQL 18.6 单用户 SQL 重跑先插入总额五、版本一，再累加三，得到八、版本二；未测试并发写者或 psql 传输。DO NOTHING 和过期版本的条件更新都返回零行。违反 CHECK 的负数输入，以及包含重复键的批次，分别抛出预期错误；脚本只捕获明确指定的错误类型，不会把任意数据库失败当成符合预期的结果。

最终断言确认，被拒绝的工作没有替换总额或版本。这个实验覆盖几种不同冲突路径，并不是延迟基准，也不保证任意合并表达式都适用于并发。把语句用于真实工作流之前，应一起审阅更新表达式、目标唯一性规则和调用方重试语义；只确认 SQL 可以执行，还不足以证明业务动作只执行了一次或保留了最新状态。

来源

PostgreSQL INSERT，冲突裁决、原子处理、EXCLUDED 与 RETURNING，已核验 2026-10-15。
PostgreSQL 约束，唯一性、检查、非空与引用完整性，已核验 2026-10-15。

窗口框架决定一次聚合能看到哪些行

Tue, 23 Feb 2027 00:00:00 +0000

窗口分区决定哪些行属于同一组，窗口帧决定其中哪些行参与当前行的某个帧敏感计算。把两种边界混淆，可能让逐笔累计变成重复显示的小计，也可能让 last_value 返回当前值，而报表原本需要的是分区最后一行的值。应先说明计算要回答什么，再选择排序和帧范围。

默认范围取决于是否排序

PostgreSQL 的默认帧是 RANGE：从分区开头到当前行的最后一个并列行。窗口 ORDER BY 中全部表达式都相等的行，属于同一个并列组。因此，有排序时的默认累计和，会包含当前行的全部同值伙伴，即使其中某些行在最终展示结果里排在后面，也已经进入当前帧。

如果窗口没有 ORDER BY，所有行都是并列行，默认帧就覆盖整个分区。因此，sum(amount) OVER (PARTITION BY account) 会重复显示账户总额；添加排序后，计算就变成有顺序的累计结果。“默认总是整个组”和“默认每次恰好多加一行”都不能同时描述这两种情况，不能把其中一种当成通用规则。

窗口顺序与最终输出顺序是分开的。外层 ORDER BY 可以改变展示排列，而不改变帧。反过来，在 RANGE 窗口内部加入唯一标识，可能把原来的并列组拆开，改变计算结果；这不只是让页面看起来稳定，而是修改了语义，应当按需求审阅。

按行、按值域和按并列组

ROWS 计算窗口排序中的位置。从前两行到当前行，最多包含三行；靠近分区起点时还会更少。它不表示三天或三分钟。如果多个事件时间戳相同，而业务需要确定的逐事件顺序，就应加入合适的唯一标识，明确同一时刻的事件谁先谁后。

RANGE 使用排序值和并列边界。指定偏移量时，PostgreSQL 要求只有一个排序表达式，并使用兼容的偏移类型，例如时间戳可以配合 interval。基于时间值域的帧按时间差纳入事件，忙时可能包含很多行，闲时可能很少。GROUPS 则按并列组计数，让帧沿不同排序值对应的组移动，同时保留组内全部并列行。这三者表达的是不同的计量单位。

first_value、last_value、nth_value，以及作为窗口函数使用的聚合，都依赖帧范围。排名和 lag、lead 的定义则基于分区顺序，并非相同规则；缩小帧不会让 lag 忘记分区中的前一行。解释某个窗口函数前，应查看该函数的语义，不能把“只看到帧内的行”套用到所有函数上。

帧成员范围不会覆盖函数本身的空值规则。PostgreSQL 18 的 last_value 及相关取值函数采用 RESPECT NULLS，末行为空时结果也为空；sum 等聚合通常忽略空输入。应先确定报表要末行取值、最后一个非空值，还是数值最大值。这些需求不能仅靠把帧延长到分区末尾就互相替代，改窗口之前要把空值案例写入验收条件。

坏掉的样子

有序默认帧中的 last_value，通常取得当前帧末尾的值，并不是整个分区末尾的值。排序唯一时，这恰好就是当前行。若要在每一行重复显示分区最后一个值，需要把结束边界写为 UNBOUNDED FOLLOWING，并提供能够定义“最后”的顺序。按时间排序后的末行值，与该字段的数值最大值，也不是同一个问题。

累计报表中，同一天的多行显示相同累计额，可能让人误以为计算漏了步骤，其实这是默认 RANGE 的并列行为。如果业务要求每个独立事件都推进一次累计，应使用明确的 ROWS 帧和确定的事件顺序。若报表本来按日期层级累计，就不应为了画出更熟悉的曲线而消除真实并列；结果是否正确要依据业务单位判断。

快速验证

把下面内容保存为 frames.sql，在可丢弃的 PostgreSQL 18 数据库中执行 psql -X -v ON_ERROR_STOP=1 -f frames.sql。两笔事件在第一天，第三笔在第二天。脚本最后回滚，临时对象和输入行都会消失。

\set ON_ERROR_STOP on
BEGIN;
CREATE TEMP TABLE sales (id integer, day integer, amount integer);
INSERT INTO sales VALUES (1,1,10),(2,1,20),(3,2,5);
CREATE TEMP VIEW framed AS
SELECT *,
 sum(amount) OVER (ORDER BY day) AS default_sum,
 sum(amount) OVER (ORDER BY day,id ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS row_sum,
 last_value(amount) OVER (ORDER BY day,id) AS default_last,
 last_value(amount) OVER (ORDER BY day,id ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) AS partition_last,
 sum(amount) OVER () AS whole_sum
FROM sales;
SELECT * FROM framed ORDER BY id;
DO $$ BEGIN
 IF (SELECT array_agg(default_sum ORDER BY id) FROM framed)
 IS DISTINCT FROM ARRAY[30,30,35]::bigint[] THEN RAISE EXCEPTION 'wrong peer frame'; END IF;
 IF (SELECT array_agg(row_sum ORDER BY id) FROM framed)
 IS DISTINCT FROM ARRAY[10,30,35]::bigint[] THEN RAISE EXCEPTION 'wrong row frame'; END IF;
 IF (SELECT array_agg(default_last ORDER BY id) FROM framed)
 IS DISTINCT FROM ARRAY[10,20,5] THEN RAISE EXCEPTION 'wrong current-frame end'; END IF;
 IF EXISTS (SELECT FROM framed WHERE partition_last IS DISTINCT FROM 5 OR whole_sum IS DISTINCT FROM 35) THEN
 RAISE EXCEPTION 'whole partition values wrong';
 END IF;
END $$;
ROLLBACK;

PostgreSQL 18.6 返回的默认累计额依次为三十、三十、三十五：第一天的两行都能看到当天完整并列组。显式 ROWS 版本按 day、id 排序，结果为十、三十、三十五。这里特意用 id 定义独立事件之间的先后，而按日期累计的默认窗口没有加入 id，两个窗口分别回答按天与逐笔的问题。

默认 last_value 列得到十、二十、五，因为它使用 day、id 的唯一顺序，每行都是自己的并列组。完整分区帧在每行返回五，不带排序的总和则在每行返回三十五。断言分别检查这些结果，防止某次修改静默改变帧范围而仍然返回看似合理的数字。

这个小数据集验证的是答案语义，不是资源成本。需要读取后续行的帧以及大型分区，可能需要较多缓冲或排序。性能调优应另用真实分布检查执行计划，同时保留这里验证的并列和边界行为；不能通过改变计算范围，换取一个更快但回答不同问题的查询。

来源

PostgreSQL 窗口表达式，帧模式、偏移与默认边界，已核验 2026-10-15。
PostgreSQL 窗口函数，依赖帧的函数及分区语义，已核验 2026-10-15。

GROUPING SETS 在一条查询中构建多层聚合

Fri, 15 Jan 2027 00:00:00 +0000

GROUPING SETS 让一条 SQL 同时生成多种聚合层级。销售报表可以一起返回地区与商品明细汇总、地区小计和总计。结果中混合了不同种类的行，因此，识别每行属于哪个层级，与算对金额同样重要；如果下游把所有结果行都当成普通明细，即使数据库计算正确，报表仍可能出错。

声明报表需要的层级

GROUPING SETS ((region,product),(region),()) 声明三种分组。第一种为每个实际出现的地区与商品组合输出一行，第二种为每个地区输出一行，空集合则汇总全部选中的输入行。这是在声明结果语义，具体执行方式由优化器选择。它可以在不同层级共享工作，但语法本身不保证固定的物理扫描次数，也不会消除排序和内存成本。

ROLLUP(region,product) 是相同前缀集合的简写，并包含空集合。交换两列顺序，会改变小计维度。CUBE(region,product) 还包括只按商品汇总的层级，覆盖维度的全部子集。六个独立维度对应六十四种分组集合，不是只输出六十四行；每种集合还可能包含很多不同分组，所以结果规模可能远大于层级数。

所有层级都汇总 FROM 和 WHERE 选出的总体。如果过滤条件只保留某个月的销售，总计也只代表该月。如果不同层级需要不同输入总体，直接对一个共享输入声明这些集合，可能并不符合需求。比较另一张报表的总额之前，要先确认日期、业务状态等筛选范围一致，不能只对照列名。

用 GROUPING 标记层级

某个分组集合没有使用的维度列，会在输出中填入 SQL NULL。但原始数据本来就可能含有 NULL，因此仅靠哪些列为空，无法可靠判断这是小计还是普通分组。GROUPING(region,product) 返回位掩码，说明当前集合缺少了哪些分组表达式；最右边的参数对应最低有效位。

在这里，零表示两个维度都参与分组，一表示省略商品，三表示两个维度都省略。真实空地区的小计与全表总计，可能同时显示空地区、空商品，但掩码不同。应把这个标记纳入输出契约，只有层级明确表示跨地区汇总时，才生成“所有地区”等展示标签。

表达式是否参与分组，与表达式的值是否非空，是不同问题。GROUPING 报告前者，其参数必须匹配查询中的分组表达式，并不是测试任意值是否为空的普通函数。向下游提供数值层级或其他无歧义标识，比把每个空值都替换为“小计”更可靠，也能保留真实缺失维度的含义。

坏掉的样子

把结果中所有 total 再相加，会让同一笔销售在每个层级重复计入。需要进一步汇总时，应先选择一个层级，或直接取已经算好的总计。平均值和去重计数更不能随意相加：没有按样本数加权的地区平均值，通常不能直接平均成整体平均值；重叠集合的去重数量也不能简单求和。聚合层级不是彼此独立的新增交易。

空分组集合在没有输入行时仍形成一个分组，但后续 HAVING 条件可以把这行过滤掉；没有这类过滤时，其中 count 为零，sum 为 NULL。因此，金额为空不等于查询没有返回总计行。应明确报表如何展示空总体，而不是把空值自动当作执行失败。还要避免无意重复声明分组集合；重复层级可能产生重复聚合行，并不代表多了一份独立证据。

快速验证

把下面内容保存为 grouping.sql，在可丢弃的 PostgreSQL 18 数据库中执行 psql -X -v ON_ERROR_STOP=1 -f grouping.sql。数据特意包含一个真实空地区，脚本用事务包住临时对象，末尾回滚清理。

\set ON_ERROR_STOP on
BEGIN;
CREATE TEMP TABLE sales (region text, product text, amount integer);
INSERT INTO sales VALUES ('east','A',10),('east','B',20),(NULL,'A',5);
CREATE TEMP VIEW levels AS
SELECT region,product,sum(amount) AS total,GROUPING(region,product) AS level
FROM sales GROUP BY GROUPING SETS ((region,product),(region),());
SELECT * FROM levels ORDER BY level,region NULLS LAST,product NULLS LAST;
SELECT sum(total) AS incorrect_retotal,
 sum(total) FILTER (WHERE level=0) AS detail_total FROM levels;
CREATE TEMP VIEW empty_level AS
SELECT count(*) AS n,sum(amount) AS total FROM sales WHERE false GROUP BY GROUPING SETS (());
SELECT * FROM empty_level;
DO $$ BEGIN
 IF (SELECT count(*) FROM levels) <> 6 THEN RAISE EXCEPTION 'wrong level count'; END IF;
 IF (SELECT total FROM levels WHERE level=3) IS DISTINCT FROM 35 THEN
 RAISE EXCEPTION 'wrong grand total';
 END IF;
 IF (SELECT total FROM levels WHERE level=1 AND region IS NULL) IS DISTINCT FROM 5 THEN
 RAISE EXCEPTION 'real null region subtotal lost';
 END IF;
 IF (SELECT count(*) FROM levels WHERE region IS NULL AND product IS NULL) <> 2 THEN
 RAISE EXCEPTION 'test did not include ambiguous NULL labels';
 END IF;
 IF (SELECT n FROM empty_level) IS DISTINCT FROM 0::bigint OR
 (SELECT total FROM empty_level) IS NOT NULL THEN
 RAISE EXCEPTION 'wrong empty-input aggregate';
 END IF;
END $$;
ROLLBACK;

PostgreSQL 18.6 返回六行：三个明细分组、两个地区小计和一个总计。east 小计为三十；真实空地区小计为五，掩码是一；全体总计为三十五，掩码是三。后两行的地区与商品列都为 NULL，直接证明依赖空值生成标签存在歧义。这里必须检查层级，而不是根据某一列看起来空白就推断。

错误地再次汇总全部 total，会得到一百零五；只汇总明细层则得到三十五。空输入查询仍返回一行，计数为零、总额为 NULL。断言检查层级行数、总计、真实空地区小计和空输入行为。最终 ORDER BY 明确安排展示顺序；GROUPING SETS 本身不承诺小计一定紧挨明细出现，消费方不能把偶然的输出排列当成分组契约。

来源

PostgreSQL 表表达式，分组集合、ROLLUP、CUBE 与省略维度，已核验 2026-10-15。
PostgreSQL 聚合函数，GROUPING 位掩码和空输入聚合，已核验 2026-10-15。
PostgreSQL 18: SELECT 与 HAVING，HAVING 对聚合分组的过滤，已核验 2026-10-15。

外键不允许引用凭空悬空

Sat, 02 Jan 2027 00:00:00 +0000

给 PostgreSQL 现有表添加外键，既是 schema 变更，也是对历史数据作出声明。新写入可以立即受到检查，而旧行仍可能保留失效引用。规划迁移或排查完整性错误时，应分别考虑约束是否执行、历史数据是否验证，以及检查发生在什么时候，不能把这三个状态混成“外键已经存在”。

执行约束不等于验证历史数据

普通启用的外键要求适用的非空引用能匹配父键。被引用列需要符合条件的唯一性，例如适当的非延迟主键、唯一约束或非部分唯一索引。子列如果没有另外声明 NOT NULL，仍然允许空值；外键本身不会把所有关系变成必填。复合引用默认使用 MATCH SIMPLE，只要一个引用列为空就不要求匹配；MATCH FULL 允许全部为空，却拒绝部分为空、部分非空的组合。

ADD CONSTRAINT … NOT VALID 跳过对现有行的初次扫描，但仍会检查新建或改变的引用，因此可以在调查旧数据时阻止新增孤儿引用。NOT VALID 并不表示规则被禁用。与此同时，数据库还不能假定所有历史行都满足该约束，迁移也不能仅凭添加语句成功就宣告数据已经完整。

VALIDATE CONSTRAINT 扫描现有数据，检查成功后才把约束标为已验证。如果仍有历史孤儿行，验证会失败，约束继续处于未验证状态。应依据权威业务关系修复数据，再次验证。为了让检查变绿而编造父记录或删除子记录，即使得到结构一致的数据库，也可能破坏真实业务事实；修复依据不能只来自外键错误本身。

把部署阶段分开处理

添加外键即使使用 NOT VALID，也会锁定引用表和被引用表，不能把它描述成完全无锁的部署方式。其价值是在添加阶段持有锁时，避免执行可能很长的历史数据扫描。VALIDATE 使用允许普通数据修改的较弱锁，但仍消耗资源，并与其他 schema 操作进行协调，所以也需要观察执行耗时和实际争用。

如果迁移目标是缩短第一个锁窗口，应先提交短暂的添加阶段，再把验证作为后续操作执行。把两步包在同一个长事务中，会让早先取得的锁一直保留到事务结束，可能抵消分阶段的收益。下面示例故意把步骤放在一个事务里，只是为了最后回滚清理整个测试环境，并不是生产锁窗口的部署模板。

PostgreSQL 不会自动给子表引用列建立索引。父键的唯一性已有索引，但更新或删除父行时，仍可能需要查找子表引用。应先检查子表已有索引，再在实际负载需要时补上适合的访问路径。声明了外键，不代表优化器一定消除关联，也不保证大范围级联删除会很快。

什么时候延迟检查

DEFERRABLE 外键可以把检查推迟到事务结束。INITIALLY DEFERRED 表示初始就采用延迟模式；SET CONSTRAINTS 可以把适用的约束切回立即检查，并检查此前尚未确认的工作。这使同一事务中先插子行、再补父行的顺序成为可能，适合需要在最终提交点保证完整性的批量操作。

延迟并不允许提交未解决的失效引用，它改变的是检查边界，而不是最终不变量。NO ACTION 可以配合延迟检查，RESTRICT 的删除限制不能延迟。级联动作也不会仅因为约束可延迟就一并推后。应一起选择动作与检查模式，不能把 DEFERRABLE 理解为临时忽略完整性而无需满足结束条件的许可。

坏掉的样子

添加语句成功后，迁移看似完成，但 convalidated 可能仍为假。因此，成功验证必须是独立的完成条件。反过来，如果高权限操作绕过执行，目录中的标记本身也不能证明数据完整。历史导入和复制流程应按实际执行的检查评估，不能只看最后留下了什么约束名字。

约束报错也可能说明正确的策略正在生效。应先定位缺少的父键和事务操作顺序，再决定是否真的需要修改规则。父子操作可能等待其他事务；为了避免等待而绕过检查，会把协调问题变成数据损坏风险，无法从根本上修复原来的调用流程。

快速验证

把下面内容保存为 foreign-key-validation.sql，在可丢弃的 PostgreSQL 18 数据库中执行 psql -X -v ON_ERROR_STOP=1 -f foreign-key-validation.sql。所有表都是临时表，末尾回滚撤销全部变更。

\set ON_ERROR_STOP on
BEGIN;
CREATE TEMP TABLE customers (id integer PRIMARY KEY);
CREATE TEMP TABLE invoices (id integer PRIMARY KEY,customer_id integer);
INSERT INTO customers VALUES (1);
INSERT INTO invoices VALUES (10,1),(11,99);
ALTER TABLE invoices ADD CONSTRAINT invoices_customer_fk
FOREIGN KEY (customer_id) REFERENCES customers NOT VALID;
SELECT convalidated FROM pg_constraint
WHERE conrelid='invoices'::regclass AND conname='invoices_customer_fk';
DO $$ BEGIN
 INSERT INTO invoices VALUES (12,99);
 RAISE EXCEPTION 'new orphan accepted';
EXCEPTION WHEN foreign_key_violation THEN RAISE NOTICE 'NOT VALID still checks new references';
END $$;
DO $$ BEGIN
 ALTER TABLE invoices VALIDATE CONSTRAINT invoices_customer_fk;
 RAISE EXCEPTION 'old orphan was not detected';
EXCEPTION WHEN foreign_key_violation THEN RAISE NOTICE 'validation found the old orphan';
END $$;
INSERT INTO customers VALUES (99);
ALTER TABLE invoices VALIDATE CONSTRAINT invoices_customer_fk;
SELECT convalidated FROM pg_constraint
WHERE conrelid='invoices'::regclass AND conname='invoices_customer_fk';
SELECT indexrelid::regclass AS child_indexes FROM pg_index WHERE indrelid='invoices'::regclass;
CREATE INDEX invoices_customer_lookup ON invoices (customer_id);
CREATE TEMP TABLE deferred_child (
 id integer PRIMARY KEY,
 customer_id integer REFERENCES customers DEFERRABLE INITIALLY DEFERRED
);
INSERT INTO deferred_child VALUES (20,7);
INSERT INTO customers VALUES (7);
SET CONSTRAINTS ALL IMMEDIATE;
DO $$ BEGIN
 IF (SELECT convalidated FROM pg_constraint
 WHERE conrelid='invoices'::regclass AND conname='invoices_customer_fk') IS DISTINCT FROM true THEN
 RAISE EXCEPTION 'constraint not validated';
 END IF;
 IF EXISTS (SELECT FROM invoices i LEFT JOIN customers c ON c.id=i.customer_id
 WHERE i.customer_id IS NOT NULL AND c.id IS NULL) THEN
 RAISE EXCEPTION 'orphan remains';
 END IF;
 IF (SELECT customer_id FROM deferred_child WHERE id=20) IS DISTINCT FROM 7 THEN
 RAISE EXCEPTION 'deferred insertion failed';
 END IF;
END $$;
ROLLBACK;

PostgreSQL 18.6 在添加后显示 convalidated 为假。新建一个指向缺失客户九十九的引用会失败，随后验证也独立发现原有孤儿行。恢复实验里已知缺失的父记录后，验证才能把标记变成真。索引列表最初只有 invoices_pkey，引用列的索引需要显式创建，不能从外键声明推断已经自动生成。

延迟检查示例先插入子行二十，再创建客户七，然后成功切换成立即检查。最终断言确认约束已验证、发票没有残留孤儿引用，并且延迟建立的关系正确。这些检查覆盖数据修复与验证的完整路径，而不只是证明一条约束声明可以成功执行。

来源

PostgreSQL ALTER TABLE，NOT VALID、验证与锁行为，已核验 2026-10-15。
PostgreSQL 约束，被引用键的唯一性、子表索引与引用动作，已核验 2026-10-15。

窗口函数把上下文带到每一行

Sun, 18 Oct 2026 00:00:00 +0000

窗口函数让报表保留每条读数，同时附加相关行的信息。一条传感器读数可以展示前值、变化量和在该传感器总量中的占比，而不必把整个传感器压缩成一行结果。能否正确解释这些附加列，取决于计算前是否明确了输入总体、分区和顺序，不能只看函数名称就认定答案符合业务。

给相邻关系明确的含义

PARTITION BY 用来划分相互独立的序列。按 sensor 分区的 lag，只比较同一传感器的值；漏掉分区条件，可能把某个传感器的第一条读数与另一个传感器的最后一条相比较。OVER 内部的 ORDER BY 决定谁是前一行。可以使用稳定的序列键；时间戳可能重复时，则应使用时间戳加唯一标识，明确同一时刻的先后关系。

lag 找的是这个有序总体中的前一行，不一定是前一分钟、前一天或上一个计划采集时刻。采集有缺口时，数据库不会自动补出缺失行。如果计算要求与前一个自然日比较，应明确建立日历关系，或先构造所需的时间序列，再做窗口计算。表里相邻的两行，并不能证明采样间隔固定。

在分区开头，lag 返回默认值，通常是 SQL NULL，用来表示没有前驱行。把它改成零，会改变首条变化量的含义，应有业务规则支持。PostgreSQL 的 lag、lead 也会保留空值语义：如果前一条读数本身为空，它不会自动越过这条记录，继续向前寻找更早的非空值。不存在前驱与前驱值为空，需要在业务解释中保持区别。

在明细旁保留总额与占比

聚合函数配合 OVER 使用时，会保留输入行，并为每行增加计算结果。sum(value) OVER (PARTITION BY sensor) 没有窗口排序，因此重复显示整个传感器分区的总额。如果未考虑默认帧就加上排序，总额可能变成累计额，随后每一行的占比分母都会改变，这不是无关紧要的展示调整。

需要小数占比时，应在除法之前转换为 numeric。整数相除可能截断小数，让较小贡献看起来全部为零。示例使用 NULLIF 把零分母转换成 SQL NULL，使无法定义的占比保持未定义状态。这个处理是一条明确规则；改为零、拒绝数据集或展示另一个状态，都是不同的业务选择，不能让算式偶然决定。

并非每个窗口函数都使用移动帧。聚合和 last_value 等函数依赖帧，而 lag、lead 在分区行之间移动。仅仅缩小 ROWS 范围，并不会重新定义 lag 所指向的前一条分区记录。应分别为每个问题选择函数和窗口，不能把一条帧公式机械地套在所有计算上。

坏掉的样子

WHERE 会先过滤窗口输入，再计算窗口值。如果在同层查询中只保留最新读数，lag 就没有旧行可看。如果要展示一条读数并保留它已有的历史上下文，应先在子查询或视图中计算窗口，再从外层过滤结果。反过来，如果排除的读数本来就不应参与比较，先过滤才正确；过滤位置要由总体定义决定。

关联也可能在窗口执行前扩张行数。一条读数关联到多个标签后，会出现多次，导致总额膨胀、相邻位置改变。添加窗口前，应确认输入仍然是一条事件对应一行的预期粒度。窗口语法不能修复重复事件，也不保证只进行一次廉价扫描；不同排序、大型分区和排序操作，都可能成为主要执行成本。

快速验证

把下面内容保存为 row-context.sql，在可丢弃的 PostgreSQL 18 数据库中执行 psql -X -v ON_ERROR_STOP=1 -f row-context.sql。脚本在事务中创建临时读数和视图，对比两种过滤位置，最后回滚整个实验。

\set ON_ERROR_STOP on
BEGIN;
CREATE TEMP TABLE readings (id integer, sensor text, value integer);
INSERT INTO readings VALUES (1,'A',10),(2,'A',15),(3,'A',12),(4,'B',0);
CREATE TEMP VIEW contextual AS
SELECT *, lag(value) OVER (PARTITION BY sensor ORDER BY id) AS previous_value,
 sum(value) OVER (PARTITION BY sensor) AS total,
 value::numeric / NULLIF(sum(value) OVER (PARTITION BY sensor),0) AS share
FROM readings;
SELECT id,sensor,value,previous_value,value-previous_value AS delta,total,round(share,3) AS share
FROM contextual ORDER BY id;
SELECT id,previous_value FROM contextual WHERE id=3;
SELECT id,lag(value) OVER (PARTITION BY sensor ORDER BY id) AS previous_value
FROM readings WHERE id=3;
DO $$ BEGIN
 IF (SELECT previous_value FROM contextual WHERE id=3) IS DISTINCT FROM 15 THEN
 RAISE EXCEPTION 'previous row was lost';
 END IF;
 IF (SELECT share FROM contextual WHERE sensor='B') IS NOT NULL THEN
 RAISE EXCEPTION 'zero denominator policy not preserved';
 END IF;
 IF (SELECT count(*) FROM contextual) <> 4 THEN RAISE EXCEPTION 'rows collapsed'; END IF;
 IF (SELECT array_agg(previous_value ORDER BY id) FROM contextual WHERE sensor='A')
 IS DISTINCT FROM ARRAY[NULL,10,15]::integer[] THEN RAISE EXCEPTION 'wrong lag sequence'; END IF;
 IF EXISTS (SELECT FROM contextual WHERE sensor='A' AND total IS DISTINCT FROM 37) THEN
 RAISE EXCEPTION 'wrong partition total';
 END IF;
 IF (SELECT previous_value FROM (
 SELECT lag(value) OVER (PARTITION BY sensor ORDER BY id) AS previous_value
 FROM readings WHERE id=3
 ) AS filtered) IS NOT NULL THEN RAISE EXCEPTION 'WHERE did not narrow the window input'; END IF;
END $$;
ROLLBACK;

PostgreSQL 18.6 保留了全部四条读数。传感器 A 的前值依次为 NULL、十、十五，变化量为 NULL、五、负三，每行总额都是三十七。numeric 占比保留三位小数后为零点二七零、零点四零五、零点三二四。逐行四舍五入后的展示值相加，不一定恰好等于一，不能据此认定原始分母错误。

从已计算的视图筛选 id 为三的行，仍得到前值十五；在源表先筛到这一行再计算 lag，则得到 NULL。传感器 B 的首行前值和零总额占比都是 NULL，但原因不同：前者没有前驱，后者没有可定义的分母。断言检查行数保留、前值序列、分区总额和过滤语义，避免重构后虽然仍返回一行，却已经丢掉原本需要的上下文。

来源

PostgreSQL 窗口教程，虚拟输入表与窗口计算后的过滤，已核验 2026-09-10。
PostgreSQL 窗口函数，lag、lead、空值和聚合帧，已核验 2026-09-10。

SQL · XB 现场笔记

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

使用相邻的左闭右开范围

缺失范围是一种运维状态

坏掉的样子

快速验证

来源

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

三个问题对应三种排名

明确分区与过滤时机

坏掉的样子

快速验证

来源

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

把关联条件写清楚

决定没有匹配时保留什么

坏掉的样子

快速验证

来源

分区把一张表拆成很多看起来还像一张的片段

逻辑父表与物理子表

分区键不只影响路由

坏掉的样子

快速验证

来源

公用表表达式把一个查询先命名再复用

先确定作用域，再讨论执行

物化是一项取舍

坏掉的样子

快速验证

来源

预备语句把取值与 SQL 结构分开

坏掉的样子

快速验证

在真实部署中观察复用

来源

查询优化器在成本上押注

成本描述的是一个模型

坏掉的样子

快速验证

根据偏差选择下一次实验

来源

组合索引贴合多列的查询

排序的是键，不是 SQL 条件

后面的键仍可能有用

把排序和工作负载一起考虑

坏掉的样子

快速验证

来源

EXPLAIN 让你看清 Postgres 会怎么做

自上而下读形状

追踪工作量与放大点

用 ANALYZE 让行数和代价对齐

坏掉的样子

快速验证

延伸阅读

来源

查询参数守住取值与 SQL 的边界

坏掉的样子

快速验证

检查完整数据路径

延伸阅读

来源

INSERT ... ON CONFLICT 把竞态收进一条语句

冲突目标定义处理范围

明确写出合并规则

坏掉的样子

快速验证

来源

窗口框架决定一次聚合能看到哪些行

默认范围取决于是否排序

按行、按值域和按并列组

坏掉的样子

快速验证

来源

GROUPING SETS 在一条查询中构建多层聚合

声明报表需要的层级

用 GROUPING 标记层级

坏掉的样子

快速验证