RANGE BETWEEN 按排序字段的值范围（而非行号）定义窗口，如时间字段需匹配数据库对INTERVAL或数值跨度的支持；它要求单列ORDER BY、排斥NULL，且在PostgreSQL/Oracle等引擎中有效，MySQL 5.7及SQL Server中不支持时间型RANGE。
什么是 RANGE BETWEEN 在窗口函数里的真实含义
RANGE BETWEEN 不是按行数切片，而是按排序字段的值范围滑动。在时间窗口场景中，它要求排序字段（比如 event_time）必须是数值型或能被数据库隐式转为数值的时间类型（如 PostgreSQL 的 INTERVAL、MySQL 8.0+ 的 TIMESTAMPDIFF 表达式），否则会静默退化为 ROWS BETWEEN 或直接报错。
常见错误现象：SELECT AVG(value) OVER (ORDER BY event_time RANGE BETWEEN INTERVAL '7 days' PRECEDING AND CURRENT ROW) 在 MySQL 5.7 或 SQL Server 上直接语法报错；在 SQLite 中根本不可用。
使用场景仅限：PostgreSQL、Oracle、Snowflake、BigQuery（需开启标准 SQL）、Doris、StarRocks 等明确支持 RANGE + 时间间隔的引擎。
关键限制：PostgreSQL 要求 event_time 是 TIMESTAMP 或 DATE 类型，且 INTERVAL 必须与之兼容；BigQuery 要求用 DATE 或 DATETIME，且写法是 RANGE BETWEEN 7 PRECEDING AND CURRENT ROW（单位由 ORDER BY 字段类型决定，不能显式写 DAY）。
PostgreSQL 中正确写法与易错点
PostgreSQL 是最常被用于演示动态时间窗口的环境，但细节极易出错。
-
ORDER BY字段必须是单个时间列（不能是EXTRACT(EPOCH FROM event_time)后的数字，否则RANGE会按秒级数值解释，导致窗口偏差） -
INTERVAL必须写在RANGE BETWEEN子句里，且单位要匹配字段精度（TIMESTAMP支持'7 days'，DATE也支持，但'7 DAYS 2 HOURS'对DATE会被截断） - 窗口内重复时间戳会导致多行“堆叠”进同一值点，
RANGE会把它们全包含——这和ROWS按物理顺序取前 N 行完全不同
SELECT
event_time,
value,
AVG(value) OVER (
ORDER BY event_time
RANGE BETWEEN INTERVAL '7 days' PRECEDING AND CURRENT ROW
) AS avg_7d
FROM events;
容易踩的坑：
- 忘记加
ORDER BY：没有它，RANGE BETWEEN语法非法 - 用
created_at::DATE排序却传INTERVAL '7 days'：可行，但所有同一天数据视为同一“点”，窗口可能突然跳变 - 在
GROUP BY后再套该窗口函数：不允许，窗口必须在聚合后计算（即不能出现在HAVING或外层聚合中）
BigQuery 和 Snowflake 的等效写法差异
BigQuery（标准 SQL）不接受 INTERVAL 字面量在 RANGE 中，而是靠字段类型自动推导单位：
- 若
ORDER BY event_date是DATE，则RANGE BETWEEN 7 PRECEDING AND CURRENT ROW表示“最近 7 天（含当天）” - 若是
DATETIME，同样写7 PRECEDING，单位是“7 微秒”——这显然不是你想要的，必须先转成DATE或用UNIX_DATE(event_datetime)
-- BigQuery 正确写法（基于 DATE）
SELECT
event_date,
value,
AVG(value) OVER (
ORDER BY event_date
RANGE BETWEEN 7 PRECEDING AND CURRENT ROW
) AS avg_7d
FROM events;
Snowflake 更接近 PostgreSQL，但要求显式 cast：
-
event_ts是TIMESTAMP_NTZ？得写RANGE BETWEEN INTERVAL '7 DAYS' PRECEDING AND CURRENT ROW - 如果是
DATE，INTERVAL '7 DAYS'也可，但INTERVAL '1 WEEK'不被支持
性能影响：所有支持 RANGE 的引擎都会对排序键建立值域索引加速查找，但若时间字段存在大量重复值（如日志按天批量入库），RANGE 窗口可能比 ROWS 慢一个数量级——因为要扫描所有同值行，而非简单跳过。
没有 RANGE BETWEEN 时的替代方案
MySQL 8.0、SQL Server 2019+、SQLite 都不支持时间类型的 RANGE，只能退到自连接或 LATERAL/OUTER APPLY 模拟，代价高但可控。
典型做法是用 WHERE 子查询关联时间范围：
SELECT
e1.event_time,
e1.value,
(SELECT AVG(e2.value)
FROM events e2
WHERE e2.event_time >= e1.event_time - INTERVAL '7 days'
AND e2.event_time <= e1.event_time) AS avg_7d
FROM events e1;
这个写法的问题很实在：
- 每行触发一次子查询，O(n²) 复杂度，万级数据就明显卡顿
- 无法利用主键索引高效定位（除非
event_time上有单独索引） - MySQL 中
INTERVAL只支持DATE/DATETIME，对TIMESTAMP要先CAST
更稳的路是预生成日期维度表 + 窗口函数模拟，或者干脆在应用层按天聚合后做移动平均——只要业务允许容忍“按天对齐”而非“任意时刻起算”，复杂度就降下来了。
真正难处理的是那些要求“每个事件精确回溯 7×24×3600 秒”的实时看板，这时候 RANGE BETWEEN 不是可选项，而是唯一合理解；但也要意识到，它背后是引擎对时间值域的深度优化，换到不支持的系统里，就得自己重造轮子。
