RANGE BETWEEN 是值域驱动的窗口定义方式，要求 ORDER BY 仅指定一个升序单调列（如 price ASC、ts ASC），且边界必须为同类型可比较值（numeric 用数字、timestamp 用 INTERVAL），不支持多列、DESC 或字符串字面量；NULL 行被排除，重复值导致窗口膨胀，性能依赖 ORDER BY 列索引。
PostgreSQL 16中RANGE窗口的值域边界必须是ORDER BY列的同类型可比较值
直接用 RANGE BETWEEN ... AND ... 做按“值”聚合（比如价格区间±10、时间范围前7天）时，PostgreSQL 要求 ORDER BY 子句里必须明确指定**且仅指定一个单调列**，且该列类型支持 +/- 运算（如 int、numeric、timestamp）。否则会报错：ERROR: RANGE is only supported with ORDER BY of a single column。
- 错误写法：
ORDER BY category, price→ 多列不被允许 - 错误写法：
ORDER BY price DESC→RANGE不支持DESC，必须是升序（隐式或显式ASC） - 正确前提：先
ORDER BY price ASC，再用RANGE BETWEEN 0 PRECEDING AND 10 FOLLOWING
如何表达“当前行值 ± N”的聚合窗口
RANGE 的 PRECEDING/FOLLOWING 是**相对于当前行 ORDER BY 列的值做加减**，不是行数偏移。例如 RANGE BETWEEN 5 PRECEDING AND 5 FOLLOWING 表示所有满足 price BETWEEN current_price - 5 AND current_price + 5 的行参与聚合。
- 对
numeric或int列：直接写数字，单位就是该列单位（如元、秒） - 对
timestamp列：必须用INTERVAL，如RANGE BETWEEN INTERVAL '7 days' PRECEDING AND CURRENT ROW - 不能混用：不能写
RANGE BETWEEN '2024-01-01' PRECEDING—— 字符串字面量不被接受 - 注意空值：含
NULL的ORDER BY列会导致整行被排除出窗口（NULLS LAST也不行）
常见陷阱：聚合结果重复、窗口为空、性能陡降
看似简单的 RANGE 窗口，在真实数据中容易产出意外结果：
- 多个相同
ORDER BY值 → 它们共享同一个窗口边界，但聚合结果会为每一行重复计算一次（不是去重后聚合） - 若当前行的值在数据中是孤立点（比如唯一高价），
RANGE BETWEEN 10 PRECEDING AND 10 FOLLOWING可能只包含自己一行，聚合结果等于单行值 - 大数据量下，
RANGE窗口无法像ROWS那样用滑动指针优化，PostgreSQL 必须对每行重新扫描匹配范围，CPU 和 I/O 开销明显更高 - 没有索引支撑
ORDER BY列时，执行计划会出现WindowAgg (actual rows=...)后紧跟全表排序，延迟显著
替代方案：用LATERAL JOIN + 子查询模拟更可控的值域聚合
当 RANGE 行为难以预测或性能不可接受时，显式子查询更可靠：
SELECT t1.id, t1.price, (SELECT AVG(t2.price) FROM items t2 WHERE t2.price BETWEEN t1.price - 10 AND t1.price + 10) AS avg_nearby_price FROM items t1;
- 优势：逻辑直白，可加
AND t2.id != t1.id排除自身；可自由加WHERE过滤；能利用price上的 B-tree 索引 - 劣势：语法稍长；若未建索引，性能可能比窗口还差；无法在单次扫描中复用中间结果
- 关键提醒：别忘了给
ORDER BY列建索引 ——CREATE INDEX ON items (price);对RANGE窗口和上述子查询都至关重要
RANGE 窗口的“值”语义很干净，但它的边界判定完全依赖数据分布和类型行为，实际使用时最常卡在 ORDER BY 单列限制、NULL 处理、以及缺乏索引导致的隐形性能崩塌。
