PostgreSQL窗口函数必须显式写全ROWS BETWEEN的起始和结束边界，RANGE易因重复值导致范围失控，时间类分析须先补全日期再用ROWS，且默认RANGE性能差，应显式指定ROWS以提升效率。
ROWS BETWEEN 必须写全边界，缺一不可
PostgreSQL 的 ROWS BETWEEN 语法要求起始和结束边界必须同时出现，否则直接报错：ERROR: window frame with offset must specify both starting and ending bounds。哪怕你只想取“当前行及之前两行”，也得写成 ROWS BETWEEN 2 PRECEDING AND CURRENT ROW，不能简写为 ROWS BETWEEN 2 PRECEDING 或漏掉 AND CURRENT ROW。
常见错误写法：
-
ROWS BETWEEN 1 PRECEDING—— 缺AND和结束边界 -
ROWS BETWEEN UNBOUNDED PRECEDING—— 同样语法不完整 -
ROWS 2 PRECEDING—— 不是合法语法，PostgreSQL 不识别
正确写法只接受成对结构，CURRENT ROW 可省略（如 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW 中的 CURRENT ROW 可不写），但起始边界绝不能单独存在。
RANGE BETWEEN 会吞掉所有同值行，不是“最近N条”
用 RANGE BETWEEN 1 PRECEDING AND CURRENT ROW 算“前一天+当天”的销售额，结果往往远超预期——因为只要 ORDER BY 列值相同（比如多个订单同属 sale_date = '2024-01-01'），RANGE 就会把所有这些同值行全拉进来，不管它们物理上隔多远。
这意味着：
- 日期字段有重复值时，
RANGE实际覆盖的行数不可控 - 想算“过去7天滚动均值”，
RANGE BETWEEN INTERVAL '7 days' PRECEDING AND CURRENT ROW看似合理，但若某天无销售记录，它不会补零，而是跳过该日，导致窗口实际跨度变短 -
RANGE模式无法配合EXCLUDE子句（如EXCLUDE CURRENT ROW），灵活性受限
所以，凡涉及时间滚动、行数精确控制的场景，优先用 ROWS，别被 RANGE 的字面意思带偏。
时间类滑动窗口必须先补日期，再用 ROWS
直接对原始销售表执行 AVG(amount) OVER (ORDER BY sale_date ROWS BETWEEN 6 PRECEDING AND CURRENT ROW)，结果会出错：缺失日期导致“6 行前”可能跨过好几天，根本不是你想要的“过去7天”。
可靠做法分三步：
- 用
GENERATE_SERIES()构造连续日期序列（PostgreSQL 专用） -
LEFT JOIN原始表，用COALESCE(amount, 0)把空日补为 0 - 在补全后的结果集上套
ROWS BETWEEN 6 PRECEDING AND CURRENT ROW
示例关键片段：
SELECT dt, sales,
ROUND(AVG(sales) OVER (ORDER BY dt ROWS BETWEEN 6 PRECEDING AND CURRENT ROW), 2) AS avg_7d
FROM (
SELECT d.dt, COALESCE(t.amount, 0) AS sales
FROM GENERATE_SERIES('2024-01-01'::DATE, '2024-01-31'::DATE, '1 day') AS d(dt)
LEFT JOIN sales_table t ON d.dt = t.sale_date
) AS filled;
这一步绕不开——没补日期，ROWS 就只是“物理行数”，不是“时间跨度”。
默认 RANGE 性能差，简单排名函数建议显式指定 ROWS
PostgreSQL 窗口函数默认使用 RANGE 框架，哪怕你没写 frame_clause。这对 ROW_NUMBER()、RANK() 这类只依赖排序顺序、不依赖值范围的函数来说，纯属浪费：RANGE 要反复检查“同行”（peer rows），而 ROWS 直接按物理位置走，快得多。
优化写法很简单：
- 把
ROW_NUMBER() OVER (ORDER BY ts)改成ROW_NUMBER() OVER (ORDER BY ts ROWS UNBOUNDED PRECEDING) - 把
RANK() OVER (PARTITION BY dept ORDER BY salary)改成RANK() OVER (PARTITION BY dept ORDER BY salary ROWS UNBOUNDED PRECEDING)
内核补丁（2025年7月）已支持这类自动优化，但显式声明更稳妥。尤其当数据量大、排序列重复值多时，性能差异可达数倍。
真正麻烦的不是语法记不住，而是容易默认相信“RANGE 按值分组听起来更合理”，结果在时间分析或性能敏感场景栽跟头。补日期、锁 ROWS、显式写边界——这三件事漏掉任何一件，窗口就可能“滑”到意料之外的地方。
