range between基于排序列的实际值（如时间戳）定义滑动窗口，与rows between按物理行数不同，能准确实现“过去7天”等动态时间范围聚合；它要求order by列为数值型或可转数值的时间类型，主流数据库支持但语法各异，mysql 8.0+和sql server不支持时间类型的range偏移。
什么是 RANGE BETWEEN 和动态时间窗口
SQL 的 RANGE BETWEEN 子句允许你按值（比如时间戳）定义滑动窗口，而不是固定行数。它和 ROWS BETWEEN 的关键区别在于：前者基于排序键的实际值做范围判断，后者只数行。如果你要“过去 7 天的销售额总和”，用 ROWS 会出错——某天没数据就跳过，导致窗口实际跨度不足 7 天；而 RANGE 能真正按时间值对齐。
PostgreSQL / Oracle / BigQuery 中 RANGE 时间窗口写法
主流支持 RANGE 的数据库要求排序字段是数值或可转为数值的时间类型（如 INTERVAL 或 epoch 秒）。常见写法是把时间转成秒/毫秒再参与计算：
SELECT
order_time,
SUM(amount) OVER (
ORDER BY EXTRACT(EPOCH FROM order_time)
RANGE BETWEEN INTERVAL '6 days' PRECEDING AND CURRENT ROW
) AS sum_7d
FROM orders;
注意：INTERVAL '6 days' 是 PostgreSQL 写法；Oracle 需用 NUMTODSINTERVAL(6, 'DAY')；BigQuery 则必须用 TIMESTAMP_SUB(order_time, INTERVAL 6 DAY) 配合 RANGE BETWEEN UNBOUNDED PRECEDING 模拟（它不直接支持 RANGE 时间偏移，得换思路）。
-
RANGE要求ORDER BY字段单调且无重复值，否则相同时间戳的多行会被归入同一窗口起点，可能漏算 - MySQL 8.0+ 不支持
RANGE对时间类型做偏移，只能用ROWS或自连接模拟 - SQL Server 完全不支持
RANGE时间窗口，ORDER BY后只接受数字列
为什么窗口结果为空或聚合值异常
典型现象是 SUM() OVER (... RANGE ...) 返回 NULL 或远小于预期——大概率是排序字段未索引、含 NULL 值，或时间精度不一致。例如：
- 表里
order_time是TIMESTAMP WITHOUT TIME ZONE，但客户端插入时带了时区偏移，导致EXTRACT(EPOCH...)结果错位 - 排序字段用了
DATE(order_time)，丢失了小时分钟，多个订单落在同一天就被视为“同一值”，RANGE窗口无法展开 - 没有
PARTITION BY却跨多用户计算，历史数据混在一起，窗口越拉越长
验证方法：先单独查 SELECT order_time, EXTRACT(EPOCH FROM order_time) FROM orders ORDER BY 2 LIMIT 10，确认数值连续性。
替代方案：当 RANGE 不可用时怎么实现动态时间窗口
在 MySQL 或 SQL Server 这类不支持时间 RANGE 的环境，得绕开窗口函数。常用做法是自连接 + 时间条件：
SELECT a.order_time, SUM(b.amount) AS sum_7d FROM orders a JOIN orders b ON b.order_time BETWEEN a.order_time - INTERVAL '6 days' AND a.order_time GROUP BY a.order_time;
但要注意性能：这种写法是 O(n²)，数据量超 10 万行就明显变慢。更稳妥的是预生成日期维度表 + LEFT JOIN，或者改用物化视图提前算好滚动聚合。
真正容易被忽略的是时间边界语义：“过去 7 天”是否包含当前时刻？不同数据库对 CURRENT ROW 的解释略有差异，PostgreSQL 把它当作一个点，而某些引擎会默认扩展为“当前值所在的所有行”。测试时务必用带毫秒的时间样本，别只拿整点数据跑。
