分析 · XB 现场笔记

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

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。

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

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。