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