PostgreSQL · XB 现场笔记

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

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。

EXPLAIN ANALYZE 把查询真的跑一遍

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

EXPLAIN 展示 PostgreSQL 的执行计划，EXPLAIN ANALYZE 还会真正执行语句并测量工作量。最有用的比较，是同一个节点的估计行数与实际行数。两者都不能单独当成结论：估计来自模型，实测则只描述特定数据、缓存、并发和插桩条件下的一次执行。不能把前者称为谎言，也不能把后者当成脱离环境的永恒事实。

先比较同一种量

计划中的 cost 是相对成本单位，不是毫秒。两个成本值分别描述启动成本与完成成本，带 LIMIT 的查询可能更重视尽早得到前几行，因此选择不同计划。actual time 才使用毫秒。即使成本和耗时恰好都打印成一百，也不能把它们直接相减或求比例；它们本来就不表示同一件事。

一个节点被重复执行时，actual rows 和节点耗时是每次循环的平均值，需要结合 loops 理解总工作量。但不能把所有节点耗时简单相加，因为父节点已经包含子节点的工作，重复相加会重复计算。并行执行时更不能用这种方式猜总延迟。先沿树看输入输出、循环次数、过滤条件和行数流向，再决定哪个位置值得调查。

BUFFERS 区分 shared、local 和临时块活动。shared hit 表示 PostgreSQL 在共享缓冲区里找到了块；shared read 只表示需要读入，操作系统仍可能从页缓存满足它，不能直接断言每次都访问了物理磁盘。临时表使用本地缓冲区，排序或哈希溢出则可能读写临时文件。父节点计数包含子节点，逐行把所有计数加起来同样会夸大 I/O。

找到有意义的估计偏差

某个选择性条件估计只返回十行，实际却返回一万行，通常值得先调查，再考虑重写其上方的连接。统计信息陈旧、分布倾斜、列间相关、参数值变化或选择性模型能力不足，都可能造成偏差。ANALYZE 可以刷新统计信息，却不能保证每个估计精确，也不会自动修好所有慢计划。先看真实数据和缺失的信息，再决定是否调整统计目标或增加扩展统计。

行数估计准确也不能证明查询高效。缺少访问路径、昂贵表达式、排序溢出、锁等待和并发争用仍可能存在。反过来，小表或需要返回大量行的查询采用顺序扫描可能正合适，不应把“没用索引”一律判为错误。分析时应保留应用实际使用的参数和查询形状，避免用一个稀有值的漂亮计划替代整个生产分布。

坏掉的样子

最危险的误解，是把 ANALYZE 当成只读预演。UPDATE 会改变行，触发器会执行，锁会被获取，SELECT 也可能调用带副作用的函数。事务末尾执行 ROLLBACK 可以恢复事务性表变化，却不能一般性撤销序列前进或外部系统副作用。对语句影响范围不确定时，应使用可丢弃的数据集，不能靠“最后会回滚”就放心在生产运行。

另一个误判来自测量本身。第一次执行会加热缓存，频繁读取时钟的成本也可能占据廉价节点的大部分时间。TIMING OFF 仍保留实际行数和整条语句的总耗时，同时避免逐节点计时。EXPLAIN 不会把普通结果集完整发送给应用，所以它不能测出传送整个响应的网络耗时。重复执行、代表性负载和应用延迟各自回答不同问题，应结合解释而不是只挑最小的毫秒值。

快速验证

用 psql 连接一个可丢弃的 PostgreSQL 18 数据库，把代码保存为 explain.sql，再运行 psql -X -v ON_ERROR_STOP=1 -f explain.sql；连接参数应明确指向实验库。这里创建的表和序列都是临时对象，最后回滚会清除它们，不需要借用已有 orders 表，也不会假定生产中存在某个字段。

\set ON_ERROR_STOP on
BEGIN;
SET LOCAL statement_timeout = '5s';
CREATE TEMP TABLE orders (id integer, status text);
INSERT INTO orders SELECT g, CASE WHEN g <= 100 THEN 'paid' ELSE 'new' END
FROM generate_series(1, 10000) AS g;
ANALYZE orders;
EXPLAIN (COSTS ON) SELECT * FROM orders WHERE status = 'paid';
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF)
SELECT * FROM orders WHERE status = 'paid';
CREATE TEMP SEQUENCE measured_calls;
SAVEPOINT before_measurement;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF)
UPDATE orders SET id = id + 10000 WHERE id <= 3;
EXPLAIN (ANALYZE, TIMING OFF) SELECT nextval('measured_calls');
ROLLBACK TO SAVEPOINT before_measurement;
SELECT count(*) AS updated_rows_after_rollback FROM orders WHERE id > 10000;
SELECT nextval('measured_calls') AS sequence_after_rollback;
DO $$ BEGIN
 IF (SELECT count(*) FROM orders WHERE status = 'paid') <> 100 THEN
 RAISE EXCEPTION 'unexpected selected row count';
 END IF;
 IF EXISTS (SELECT FROM orders WHERE id > 10000) THEN
 RAISE EXCEPTION 'UPDATE was not rolled back';
 END IF;
 IF (SELECT last_value FROM measured_calls) <> 2 THEN
 RAISE EXCEPTION 'sequence advance unexpectedly rolled back';
 END IF;
END $$;
ROLLBACK;

夹具恰好包含一百条 paid 订单。实际执行的 SELECT 应显示一百行通过过滤、九千九百行被过滤。UPDATE 下方的扫描节点处理三行，但没有 RETURNING 时顶层节点返回零行；这个零不代表没有更新。回滚到保存点后，更新后的行数回到零，但下一次序列值是二，因为被测 SELECT 已经消耗了第一个值。代码为这些结果提供断言，而不是仅打印一个看似合理的计划。

在 PostgreSQL 18.6 上这些断言通过。具体计划、缓冲区计数、耗时和打印格式可以变化，稳定预期是行数、回滚效果与序列前进。五秒 statement timeout 限制本实验中单条语句的执行时间，但不会把任意生产写操作变成安全检查。临时对象和受控数据是这个实验可复现的前提，不能移除后仍声称风险相同。

来源

PostgreSQL EXPLAIN，真实执行的副作用和测量选项，已核验 2026-09-10。
PostgreSQL 使用 EXPLAIN，成本、循环次数与缓冲区解释，已核验 2026-09-10。
PostgreSQL 规划器统计信息，估计与统计模型的边界，已核验 2026-09-10。
PostgreSQL 序列函数，不随回滚撤销的序列前进，已核验 2026-09-10。

pg_stat_statements 在有效采集窗口内比较查询代价

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

pg_stat_statements 把语句执行归组并累计代价。它既能找出调用很频繁、单次很短但总耗时很大的查询，也能帮助定位单次特别慢的查询。这是两个不同问题，任何一种排名都不能单独证明某项修改会改善业务延迟。执行时间也不等于处理器消耗、存储等待或完整请求时长。先明确要优化的现象，再选择统计列，才能避免把排行榜本身当成优化结论。

归组有用，但有明确边界

PostgreSQL 18 通常把代表性查询文本中的常量替换为参数符号，并按分析后的结构归组。条目身份包含用户、数据库、查询标识，以及是否为顶层执行；查询文本并不是完整身份。对象解析不同，可能让相同文本进入不同条目；相关分组范围内，也存在哈希碰撞把无关结构合并的微小可能。因此监控应保留足够身份字段，而不是只截取一段 SQL 当作永远可靠的主键。

代表性文本用于诊断，不是每条原始请求的审计流水。有些工具语句或归一化失效场景仍会保留字面量，应限制访问并避免把秘密嵌进 SQL。查询标识不承诺跨大版本或任意目录变化保持稳定。PostgreSQL 18 还会对某些长度不同的常量列表归一化；换到另一个版本时，需要查对应手册，不能把当前显示形式当成所有历史版本的统一行为。

根据问题选择排名

总执行时间适合寻找累计数据库工作量大的对象。平均值、最大值与离散程度描述单次调用的分布特点，但它们不是分位数，也不能单独指出原因。波动可能来自参数、缓存状态、竞争或计划变化。看到标准差较大时，应继续检查计划和等待，不能直接宣布发生了锁竞争；平均较高也不自动意味着规划器选择错误。

并发会话的执行区间会重叠，所以累计执行时长可以超过统计窗口的墙钟时间。这不证明服务器重启过，也不证明数据无效。启用计划统计时，规划耗时另有字段。共享块读取表示数据库缓冲管理器发起的读取，仍可能由操作系统缓存满足。乘以服务器块大小后得到的是请求读取量，不是物理设备实际流量；开启输入输出计时增加耗时测量，基础块计数并不依赖它。

坏掉的样子

模块需要在服务器启动时通过 shared_preload_libraries 加载，检查所用数据库也需要创建 SQL 扩展。查询标识计算必须可用，通常由 compute_query_id 的 auto 或 on 提供，也可以来自外部模块。缺少配置、权限限制和关闭跟踪是不同失败，应读取实际错误，而不是把任何缺失条目都解释成没有负载发生。监控查询能够运行，也不代表它有权看见所有其他用户的文本。

可靠增量要求条目身份与采集窗口都可比较。PostgreSQL 18 提供每条记录的 stats_since、最小最大值的独立起点，以及全局重置和淘汰信息。定向重置或淘汰可以只破坏一个条目的连续性，而不重置整个视图。差值非负也不足以证明窗口连续：重置之后积累足够工作，可能把异常掩盖。新条目和窗口变化应重新建立基线，不能跨越它们直接做减法。

快速验证

使用全新的 PostgreSQL 18 可丢弃数据库，预先加载模块、启用查询标识，并让测试角色能够使用或安装扩展。通过新的会话执行下面 SQL，任何错误都应作为失败处理。实验创建一个测试表，观察两次调用后删除表，不重置任何已有统计，因此不会为了演示排名而破坏监控窗口。

CREATE EXTENSION IF NOT EXISTS pg_stat_statements;
CREATE TABLE pgss_demo (id integer);
INSERT INTO pgss_demo SELECT generate_series(1,1000);
SELECT sum(id) FROM pgss_demo WHERE id < 100;
SELECT sum(id) FROM pgss_demo WHERE id < 500;
SELECT query,calls,rows,round(total_exec_time::numeric,3) AS total_ms,
 round(mean_exec_time::numeric,3) AS mean_ms,stats_since
FROM pg_stat_statements
WHERE query LIKE 'SELECT sum(id) FROM pgss_demo WHERE id < %';
DO $$ BEGIN
 IF (SELECT count(*) FROM pg_stat_statements
 WHERE query LIKE 'SELECT sum(id) FROM pgss_demo WHERE id < %') <> 1
 OR (SELECT sum(calls) FROM pg_stat_statements
 WHERE query LIKE 'SELECT sum(id) FROM pgss_demo WHERE id < %') <> 2 THEN
 RAISE EXCEPTION 'expected one normalized shape with two calls';
 END IF;
END $$;
SELECT userid,dbid,toplevel,queryid,calls,
 round(total_exec_time::numeric,3) AS total_ms,
 round(mean_exec_time::numeric,3) AS mean_ms
FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 10;
SELECT userid,dbid,toplevel,queryid,calls,
 round(mean_exec_time::numeric,3) AS mean_ms
FROM pg_stat_statements ORDER BY mean_exec_time DESC LIMIT 10;
SELECT dealloc,stats_reset FROM pg_stat_statements_info;
SELECT round((sum(shared_blks_read)::numeric *
 current_setting('block_size')::numeric)/1073741824,6) AS requested_read_gib
FROM pg_stat_statements;
DROP TABLE pgss_demo;
SELECT 'pgss fixture completed' AS completion;

两个求和结果分别是四千九百五十和十二万四千七百五十。过滤后的统计应只有一个归一化查询形态，调用次数为二；断言明确核对这个事实。对于如此小的负载，两种通用排名完全可能相同。它们展示的是排序依据的区别，不制造必然不一致的承诺。对双精度耗时先转换为 numeric，才可以使用指定小数位数的两参数 round。

本轮在 PostgreSQL 18.6 单用户模式中加载真实扩展，完整执行并通过上述 SQL。该方式无需监听端口，验证了 SQL 与扩展行为，但没有测试客户端传输、并发会话、生产开销或监控权限配置。耗时只作为本次观察，不作为稳定基准。根据生产排名采取行动之前，应采集窗口可比的快照，明确用户和数据库范围，理解条目对应的真实负载，并在修改之后重新测量应用结果。

来源

PostgreSQL 18 pg_stat_statements，归组键、耗时类型、归一化、重置与条目窗口，已核验 2026-10-15。
PostgreSQL 18 monitoring statistics，累计观察及缓冲读取与物理输入输出的区别，已核验 2026-10-15。
PostgreSQL 18 statistics configuration，查询标识与可选输入输出计时，已核验 2026-10-15。

Postgres 的 jsonb 专为查询而生

Sat, 04 Dec 2027 00:00:00 +0000

PostgreSQL 提供两种 JSON 存储类型，它们承担的表示成本不同。json 验证并保留输入文本，jsonb 把文本转换成拆解后的二进制值。两者都能提取字段和路径。选择类型时，需要回答的是是否必须保留文本形态、是否反复处理文档，以及真实查询需要哪些算子，而不是简单判断能不能读取内部字段。

保留文本还是保留结构值

json 会保留无意义空白、对象键的顺序和重复对象键。处理函数仍需要解析这些文本，遇到重复键时，以最后一个值作为有效值。因此，存储保留了重复项，并不代表每个消费方都会得出同样解释。不要把重复键当成应用契约中有意义的数据结构，否则跨语言解析时很容易产生分歧。

jsonb 去掉无意义空白和对象键顺序，同一个对象键只保留最后一次出现的值。这里说的是对象：数组仍然保留元素顺序和重复元素。数组的包含判断有自己的匹配规则，不能因为包含查询把两个数组视为匹配，就反推存储时发生了排序或去重。表示、相等比较和包含关系是三个需要分别理解的问题。

这种二进制格式属于 PostgreSQL，并不是 BSON，也不是可跨系统使用的签名格式。jsonb 输出的文本没有承诺遵循某个外部 JSON 规范化算法。如果签名覆盖原始请求字节，应另外保留这些字节，例如使用 bytea，并针对该表示验证签名。json 保留的是接收后的 JSON 文本；客户端编码转换和协议处理可能已改变网络上的原始字节，因此不能把它当成任意请求的逐字节归档。

两种类型都支持路径提取

两者都支持用 -> 提取 JSON 值，用 ->> 提取文本，以及用 #>、#>> 读取嵌套路径。读取 json 内部字段时，不需要先把整篇文档强制转换成 jsonb。性能区别在于重新解析文本还是处理已经拆解的表示，而不是 json 缺少这些操作符。

jsonb 还支持结构包含、键存在判断和 GIN 等索引策略。从两种类型提取出的标量表达式，也可以按实际需要建立适当的表达式索引。能否使用索引仍取决于准确的表达式、算子和负载，选了 jsonb 不代表任意嵌套条件都会变快。经常参与关联、约束或排序的字段，往往更适合独立的有类型列，以明确数据契约并方便优化。

输入成本和处理成本需要同时考虑。jsonb 转换时要做额外工作，某些文档占用的空间也可能更大。两种类型接受的输入几乎相同，但并非完全一致：PostgreSQL 的 numeric 范围限制和更严格的 Unicode 处理，会让某些可以存成 json 文本的输入无法转换成 jsonb。迁移现有列前，应检查有代表性的真实载荷，特别是极大数字和转义字符，不能只用一个短小示例推断整个数据集。

坏掉的样子

把 json 改为 jsonb，可能破坏导出程序依赖的原始表示。换类型也不等于执行应用 schema 校验：合法的 JSON 字符串、数字或数组仍然是 JSON，即使业务只接受对象。需要哪些字段、字段能取什么值，应通过实际结构和业务约束表达，不能把语法有效误当成业务有效。

更隐蔽的问题是默认所有解析器对重复键的解释一致。数据库采用最后值，并不能证明上游签名程序或下游读取程序采用了同一规则。需要一致理解的边界，应拒绝有歧义的输入。读取结果时，也要区分路径缺失、JSON null 和 SQL NULL；把三者全部转换成没有说明的空字符串，会丢掉排查和校验所需的信息。

快速验证

把下面内容保存为 json-types.sql，在可丢弃的 PostgreSQL 18 数据库中执行 psql -X -v ON_ERROR_STOP=1 -f json-types.sql。脚本只在事务内创建一张临时表，末尾回滚，数据和对象都不会留下。

\set ON_ERROR_STOP on
BEGIN;
CREATE TEMP TABLE sample (raw json, parsed jsonb);
INSERT INTO sample VALUES ('{ "b": 2, "a": 1, "a": 3 }','{ "b": 2, "a": 1, "a": 3 }');
SELECT raw::text, parsed::text, raw->>'a' AS json_a, parsed->>'a' AS jsonb_a FROM sample;
SELECT '{"user":{"name":"Ada"}}'::json #>> '{user,name}' AS json_path;
DO $$ BEGIN
 IF (SELECT raw::text FROM sample) IS DISTINCT FROM '{ "b": 2, "a": 1, "a": 3 }' THEN
 RAISE EXCEPTION 'json text was changed';
 END IF;
 IF (SELECT parsed FROM sample) IS DISTINCT FROM '{"a":3,"b":2}'::jsonb THEN
 RAISE EXCEPTION 'unexpected jsonb value';
 END IF;
 IF (SELECT raw->>'a' FROM sample) IS DISTINCT FROM '3' THEN
 RAISE EXCEPTION 'json extraction did not use the last duplicate key';
 END IF;
 IF '[2,1]'::jsonb = '[1,2]'::jsonb THEN
 RAISE EXCEPTION 'jsonb array order was ignored';
 END IF;
 IF '[2,1,2]'::jsonb = '[2,1]'::jsonb THEN
 RAISE EXCEPTION 'jsonb duplicate array elements were ignored';
 END IF;
END $$;
DO $$ BEGIN
 PERFORM '{broken'::json;
 RAISE EXCEPTION 'invalid JSON accepted';
EXCEPTION WHEN invalid_text_representation THEN RAISE NOTICE 'invalid JSON rejected';
END $$;
ROLLBACK;

PostgreSQL 18.6 的实测结果是：raw 保持原来的空白文本；parsed 显示重新格式化、包含 a=3、b=2 的对象；两种提取表达式都返回 3。直接在 json 上读取嵌套路径，也能得到 Ada。断言检查这些语义，并分别验证数组相等比较会考虑顺序与重复元素；捕获到预期的非法输入错误后，会打印“invalid JSON rejected”提示。如果错误类型变化或无效 JSON 被接受，脚本不会把它默认为成功。

这个实验验证表示与提取行为，并没有比较速度或存储效率。迁移生产列前，还要分别测量真实文档大小、写入频率和查询计划，确认转换失败数据的处理方式，以及哪些表示信息允许丢失。只有把这些取舍说明清楚后，才能决定是否替换原始数据；不能仅凭示例成功就删除仍然需要用于回放或签名校验的原文。

来源

PostgreSQL JSON 类型，表示形式、输入限制和索引，已核验 2026-10-15。
PostgreSQL JSON 函数与操作符，两种类型的提取操作符和空值行为，已核验 2026-10-15。

建议锁寿命属于连接或事务

Wed, 24 Nov 2027 00:00:00 +0000

建议锁让应用使用一个标识来协调工作，不要求这个标识对应数据库里某一行。比如，多名工作者可以约定，同一时间只能有一个连接刷新某份报表。PostgreSQL 负责管理锁的持有与竞争，应用则负责定义标识的业务含义，以及哪些操作必须先拿锁才能执行。这个分工决定了它能提供的保障，也决定了绕过协议时会发生什么。

坏掉的样子

建议锁的键只能是一个大整数，或者两个普通整数，没有接受文本名字的函数重载。这两种键空间彼此独立。如果应用通过哈希把名称映射为数字，必须明确一致的编码规则，也要考虑碰撞；同一资源被不同算法映射到不同数字，同样会破坏协调。直接维护有文档的整数命名空间，通常比隐藏在各个调用方里的临时哈希规则更容易核对。

建议锁是参与者共同遵守的协议。忽略它的连接，仍然可以更新所谓受保护的表行；它不能代替唯一约束、事务或权限检查。会话锁在回滚后仍然保留，直到对应次数的解锁完成，或服务器结束该会话。事务锁则随事务结束释放。如果处于自动提交模式，一条语句取得的事务锁，在后续语句开始之前就已经释放，无法保护接下来才执行的工作。

快速验证

本轮没有重跑原样保留的双会话示例：单用户后端不能复现会话间竞争。以下结果保留为预期，不是新的并发验证。

准备同一个 PostgreSQL 18 可丢弃数据库，开启甲、乙两个全新的 psql -X -v ON_ERROR_STOP=1 会话。为本实验预留下面的整数键，不要与已有业务约定混用。按照块的顺序切换终端。甲先创建计数器：

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

甲传入显式文本类型的键，预期返回 42883，即不存在匹配的函数。故意报错这一段结束后恢复遇错停止设置：

\set ON_ERROR_STOP off
SELECT pg_advisory_lock('job-name'::text);
\echo text_key_state :SQLSTATE
\set ON_ERROR_STOP on

甲在事务里把同一把会话锁取两次，然后回滚。注意函数名使用的是会话级形式：

BEGIN;
SELECT pg_advisory_lock(8610,2);
SELECT pg_advisory_lock(8610,2);
ROLLBACK;

乙尝试非阻塞取锁，接着故意不遵守建议锁协议，直接更新计数器：

SELECT pg_try_advisory_lock(8610,2);
UPDATE advisory_demo.counter SET n=n+1 WHERE id=1 RETURNING n;

取锁返回假，更新却返回一。两个结果分别证明：甲的回滚没有释放会话锁；建议锁也没有自动阻挡普通表写入。甲现在解锁一次：

SELECT pg_advisory_unlock(8610,2);

虽然解锁返回真，乙仍然无法获得同一把锁：

SELECT pg_try_advisory_lock(8610,2);

甲还需要解除第二次获取：

SELECT pg_advisory_unlock(8610,2);

这时乙能够成功取锁，并明确释放自己刚获得的那一次持有：

SELECT pg_try_advisory_lock(8610,2);
SELECT pg_advisory_unlock(8610,2);

两个调用都返回真。同一会话重复成功取锁会累加持有次数，所以一次解锁成功，并不能证明该会话已经完全放弃资源。下一步，甲对另一个键使用事务级函数，并保持显式事务打开：

BEGIN;
SELECT pg_advisory_xact_lock(8610,3);

乙的非阻塞事务锁请求返回假，说明甲仍拥有该键：

SELECT pg_try_advisory_xact_lock(8610,3);

甲回滚，结束事务级持有：

ROLLBACK;

乙在自动提交模式下重新申请，这次返回真：

SELECT pg_try_advisory_xact_lock(8610,3);

紧接着，甲也在自动提交模式下申请相同的事务锁，仍返回真：

SELECT pg_try_advisory_xact_lock(8610,3);

两个真是先后成功，不是同时拥有同一把互斥锁。每条语句的隐式事务结束时，就已释放当次锁。此刻双方都不能认为自己还保护着未来的临界区。最后由甲核对计数值仍是一，并删除实验模式：

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

非阻塞取锁失败不会增加需要释放的持有次数。只有成功获取，才会成为当前会话或事务实际拥有的锁。

让持有寿命覆盖完整操作

如果被保护的数据库工作可以放在一个事务中，应显式开启事务、获取事务锁，再完成读取、判断和写入，最后结束事务。非阻塞取锁返回假时，意味着调用方没有取得所有权；此时应跳过或重新安排任务，不能无视返回值继续执行受保护工作。阻塞版本可能等待，因此取锁预算和重试策略也必须纳入这个业务操作的总时限。

只有确实需要跨越多次事务的持有周期时，才选择会话锁，而且获取、工作和释放必须使用同一条物理数据库连接。如果持锁后把连接还给池，后台会话可能继续持锁，却开始服务不相关的请求。事务池化尤其不能支持“下次请求仍回到原来那个持锁会话”的假设。这里要核对真实连接寿命，而不是仅看应用对象是否还是同一个名字。

服务器结束会话时会自动清理会话锁，不存在会话已经终止但锁永久残留的正常语义。不过，网络连接丢失的检测可能有延迟，不能假定客户端消失后其他工作者立即获得锁。锁也不记录任务是否已经完成。后续工作者取得所有权后，仍应检查已提交状态，判断是否需要执行，以及重复执行是否符合任务语义，不能把“我现在拿到了锁”误当成“此前无人完成过”。

来源

PostgreSQL 18 建议锁函数，允许的键类型及阻塞、非阻塞接口，已核验 2026-10-15。
PostgreSQL 18 显式锁，建议锁持有、重复获取和事务语义，已核验 2026-10-15。

部分唯一性约束保护有效子集

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

部分索引只为满足谓词的行保存索引项。需要的子集很小时，它可以缩小索引，但也可以表达只对这个子集生效的完整性规则。例如，同一个座位允许保留多条历史预订，却只能有一条当前有效预订。部分唯一索引可以把这条规则放在数据库边界上执行，而不只是提高某条查询的速度。

成员资格随谓词变化

CREATE INDEX ... WHERE active 只包含 active 为 true 的行，false 和 null 都不满足条件。是否允许 null 是独立的模型选择；下面实验把 active 定义为非空，使每条预订明确处于有效或无效状态。索引键也不必就是谓词中出现的列：这里用 seat 作为键，用 active 决定哪些行参与。

普通写入会改变成员资格。无效记录变成有效记录时，必须进入索引并接受检查；有效记录失效后，则离开当前有效子集。这个边界不是一旦建索引就永远固定的历史分界线。每次写入仍要判断谓词，状态切换也有维护成本，所以索引更小不意味着所有更新都免费，更不能无条件承诺写入一定更快。

唯一性可以只针对子集

在 seat 上建立 WHERE active 的唯一索引，会拒绝同一个座位出现两条有效记录，却允许任意多条无效历史记录。即使没有 SELECT 使用这个索引，数据库仍会执行唯一性检查。因此查询加速与数据完整性是保留索引的两种不同理由，不能只看扫描计数为零就把承担约束的索引删除。

应用先查“有没有”再插入，比数据库约束弱，因为另一个事务可能在检查与写入之间插入。唯一索引会在 PostgreSQL 中协调冲突写入，失败方需要处理唯一性错误或明确选择的冲突策略。下面夹具按确定顺序验证拒绝行为；并发协调属于数据库约束契约，不代表已经实现支付、扣款和跨服务预订的完整业务流程。

查询也要表达同一边界

规划器把部分索引用于访问路径时，必须能够证明查询条件蕴含索引谓词。仅按 seat 查询，并不能证明调用方只需要有效记录，因为历史记录也可能匹配。显式查询 active 记录才可能符合条件，但小表仍可能采用更便宜的顺序扫描。逻辑上相似的表达式，也只有在规划器能够识别其蕴含关系时才有用，不能仅凭人眼觉得相近。

也不要用数百个互相重叠的部分索引模拟分区。规划与维护成本会增长，优化器不会自动把这些独立索引当成一套协调的分区结构。谓词应来自稳定的工作负载或明确完整性需求，再通过真实查询与状态转换验证。建立索引不是给数据打上一个永不变化的标签，而是维护一个持续受规则约束的子集。

坏掉的样子

查询忘写有效状态条件时，可能把旧预订和当前预订一起返回，而唯一索引本身完全没有失效。反过来，应用把这个索引误当成全表唯一，也可能在业务层错误拒绝合法历史。应写清规则约束的是所有行还是当前子集，并同时测试这两类数据。否则列表页、恢复旧记录和导入流程很容易对同一座位产生不同理解。

重新激活失败是另一个关键边界。把旧记录改回 active，可能与当前持有人冲突。失败后旧记录应该仍保持无效，并向调用方报告冲突，不能悄悄替换已有有效预订。批量导入与状态迁移也必须接受同样检查，不能因为它们是运维任务就绕开当前有效唯一性；这样才能让不同写入入口共享同一规则。

快速验证

保存为 partial-unique.sql，使用 psql -X -v ON_ERROR_STOP=1 -f partial-unique.sql 连接可丢弃的 PostgreSQL 18 数据库。实验只创建会话临时预订表，不接触真实座位库存；所有记录和状态变化都在代码中给出。

\set ON_ERROR_STOP on
BEGIN;
CREATE TEMP TABLE reservations (id integer PRIMARY KEY, seat text NOT NULL, active boolean NOT NULL);
CREATE UNIQUE INDEX one_active_seat ON reservations (seat) WHERE active;
INSERT INTO reservations VALUES (1,'A1',true),(2,'A1',false),(3,'A1',false);
DO $$ BEGIN
 INSERT INTO reservations VALUES (4,'A1',true);
 RAISE EXCEPTION 'two active reservations accepted';
EXCEPTION WHEN unique_violation THEN RAISE NOTICE 'active duplicate rejected';
END $$;
UPDATE reservations SET active=false WHERE id=1;
INSERT INTO reservations VALUES (4,'A1',true);
DO $$ BEGIN
 UPDATE reservations SET active=true WHERE id=2;
 RAISE EXCEPTION 'reactivation bypassed uniqueness';
EXCEPTION WHEN unique_violation THEN RAISE NOTICE 'conflicting reactivation rejected';
END $$;
SELECT active,count(*) FROM reservations GROUP BY active ORDER BY active;
SELECT id FROM reservations WHERE active AND seat='A1';
DO $$ BEGIN
 IF (SELECT id FROM reservations WHERE active AND seat='A1') IS DISTINCT FROM 4 THEN
 RAISE EXCEPTION 'wrong active reservation';
 END IF;
 IF (SELECT count(*) FROM reservations WHERE NOT active) <> 3 THEN
 RAISE EXCEPTION 'history was not preserved';
 END IF;
END $$;
ROLLBACK;

最初的有效重复被拒绝，而两条历史重复成功保留。把一号预订设为无效后，四号预订可以取得该座位；再把二号重新激活则失败，因为四号仍有效。最后应有三条无效记录、一条有效记录，有效标识为四。断言同时检查当前持有人与历史数量，避免只验证拒绝消息而遗漏错误的数据变更。

这些检查在 PostgreSQL 18.6 通过。异常块只捕获预期的唯一性违反；如果本应失败的操作意外成功，后面的不同异常会让脚本失败。最后回滚移除夹具。实验验证子集成员资格与唯一性转换，不证明支付原子性、分布式库存一致性，也没有测量巨大历史表上的性能收益。

来源

PostgreSQL 部分索引，谓词成员资格与部分唯一性，已核验 2026-10-15。
PostgreSQL CREATE INDEX，唯一索引检查与谓词，已核验 2026-10-15。

覆盖索引有条件地避免堆访问

Thu, 14 Oct 2027 00:00:00 +0000

覆盖索引包含某一条查询需要的值，PostgreSQL 有时可以通过 index-only scan 直接返回它们，避免访问对应的堆元组。这里的“有时”很关键：列是否齐全属于结构条件，执行时能否真正跳过堆访问，还取决于可见性信息。计划里出现 Index Only Scan，并不能单独证明没有访问表数据，更不能据此宣称任何写入状态下都能省掉堆读取。

覆盖实际返回的列

按 sku 查价格时，可以建立 sku 的 B-tree，并用 INCLUDE (price) 把价格作为附加值存进去。搜索由 sku 键引导，附加的 price 不会自动成为第二个搜索键，也不提供按价格排序的顺序。如果这是唯一索引，唯一性约束针对键列，而不是键与附加列的整体组合。这些区别决定它究竟能回答哪些查询。

查询后来增加返回列，就可能破坏覆盖前提。例如 description 不在索引中，执行器需要从其他位置取得它，通常就是堆表。随手改成 SELECT 星号，也可能把原本专门优化的查找变成另一种访问模式。应从实际过滤条件和投影列出发，结合表达式与可见性需求设计，而不是把全部字段都塞进一个预想中的万能覆盖索引。

并非所有索引方法都能还原 index-only 执行所需的完整值。B-tree 支持这种扫描，GIN 通常保存的是从原值提取的键，而不是完整原值，因此不支持 index-only scan。索引不仅要包含或能够还原所需数据，也要支持对应操作。其他数据库也使用“覆盖索引”这个名称，但不能据此把 PostgreSQL 的可见性机制直接套过去。

可见性映射决定是否访问堆

PostgreSQL 必须判断候选元组是否对当前 MVCC 快照可见，索引项没有保存全部所需可见性信息。Index-only scan 会检查堆页在 visibility map 中的 all-visible 位；该位已设置时，才能直接返回索引中的值，而不读取堆元组。这样省下的是堆访问，仍然需要读取索引和可见性映射，并不等于完全没有 I/O。

写入可能清除页的 all-visible 状态，导致之后的查询重新访问堆，即使计划名称没有改变。VACUUM 可以在页内元组满足可见性条件时设置该状态，长事务和持续更新都会影响这一过程。它是页级属性，不是某个单独字段的属性；同一页上其他行被修改，也可能影响当前行的可见性检查路径。因此“这一行没改过”也不能直接推出零堆访问。

坏掉的样子

最常见的误判是只看 EXPLAIN 的计划标签就宣布优化成功。应在 EXPLAIN ANALYZE 中同时查看 Heap Fetches、相关缓冲区和实际返回值。频繁写入的表可能不断需要堆检查，读取收益下降，却仍承担附加值的复制与维护成本。每次业务写入后都运行 VACUUM，并不能代替对真实读写比例和维护成本的评估。

宽大的附加列还会占用磁盘和缓存，增加索引维护工作，甚至超过索引元组尺寸限制。更新 INCLUDE 列需要维护索引，也可能阻止原本可行的 heap-only update。应只覆盖读收益足以抵偿写入和存储成本的字段；覆盖索引不是免费物化的整表副本，也不能只用一次静态查询的耗时决定是否值得长期保留。

快速验证

把 SQL 保存为 covering.sql，运行 psql -X -v ON_ERROR_STOP=1 -f covering.sql，连接可丢弃的 PostgreSQL 18 数据库。保持 psql 默认自动提交，不要在外面加 BEGIN，因为 VACUUM 不能在显式事务块中运行。实验表是会话临时表，不会修改其他连接的数据，断言失败退出后临时表也会随会话消失。

\set ON_ERROR_STOP on
CREATE TEMP TABLE products (sku integer, price integer);
INSERT INTO products SELECT g, g*10 FROM generate_series(1,10000) AS g;
CREATE INDEX products_price_lookup ON products (sku) INCLUDE (price);
VACUUM (ANALYZE) products;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF)
SELECT price FROM products WHERE sku=4321;
UPDATE products SET price=price+5 WHERE sku=4321;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF)
SELECT price FROM products WHERE sku=4321;
VACUUM (ANALYZE) products;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF)
SELECT price FROM products WHERE sku=4321;
DO $$ BEGIN
 IF (SELECT price FROM products WHERE sku=4321) IS DISTINCT FROM 43215 THEN
 RAISE EXCEPTION 'covering lookup returned an obsolete price';
 END IF;
END $$;
DROP TABLE products;

第一次 VACUUM 让静止夹具满足无堆读取条件。在 PostgreSQL 18.6 上，三个计划都显示 Index Only Scan，但 Heap Fetches 依次是零、价格更新后的二、再次 VACUUM 后的零。断言同时确认返回的新价格是 43215，而不是旧索引值。实验最后显式删除临时表，避免把清理当成读者需要猜测的步骤。

中间的具体访问次数可以随实现和页状态变化，关键是相同计划标签下仍可能发生堆访问。Heap Fetches 统计堆访问，并不等于物理磁盘读取次数，所需页仍可能已经在缓存中。这个受控实验也不承诺生产中一次 VACUUM 就让所有页立刻 all-visible。真正评估覆盖收益时，应观察代表性查询在实际更新活动前后的表现，同时计算附加数据带来的维护成本，而不是只挑清理刚完成时的最好结果。

来源

PostgreSQL index-only 扫描，可见性映射与附加值，已核验 2026-09-10。
PostgreSQL CREATE INDEX，INCLUDE 语义与索引限制，已核验 2026-09-10。

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。