RANGE BETWEEN 按值域而非行序滑动，依赖排序列的实际数值差；若ORDER BY列存在重复、精度不足或类型不支持减法，会导致窗口计算错误。
为什么 RANGE BETWEEN 有时不按预期工作
根本原因在于：SQL 标准里 RANGE 是按「值域」而非「行序」滑动，它依赖排序列的**实际数值差**，不是第几行。如果你用 ORDER BY timestamp 却没注意时间精度或存在重复值，窗口就可能吞掉不该吞的行，或漏掉该算的行。
常见错误现象：COUNT(*) 结果远少于预期；AVG(value) 在相同时间戳下突变；窗口“卡住”不动（尤其在 timestamp 列有大量重复值时）。
- 必须确保
ORDER BY列是单调、高精度且尽量无重复的，比如用ORDER BY event_time, event_id消除并列 -
RANGE BETWEEN INTERVAL '1' HOUR PRECEDING AND CURRENT ROW要求event_time是TIMESTAMP类型，DATE或字符串会直接报错或静默失效 - PostgreSQL 支持
RANGE+INTERVAL，但 MySQL 8.0+ 仅支持RANGE配合数字偏移（如RANGE BETWEEN 3600 PRECEDING AND CURRENT ROW），前提是排序列是数值型
RANGE 和 ROWS 在固定时间窗口里到底选哪个
选 RANGE 是为了真正按「时间跨度」聚合——比如“过去一小时所有订单金额总和”，不管这一小时内来了多少条记录；而 ROWS 只能表达“最近 100 行”，和时间无关。
但代价明确：性能通常更差，因为引擎要反复计算值差；且无法跳过排序列的重复值——如果 10 条记录都落在同一秒，RANGE BETWEEN INTERVAL '1' SECOND PRECEDING AND CURRENT ROW 会把这 10 条全拉进来，哪怕你只想看“前一条时间点以来”的数据。
- 用
RANGE前先确认你的排序列分布：执行SELECT COUNT(*), COUNT(DISTINCT event_time) FROM t，如果两者接近，说明适合；如果相差一个数量级，就得加辅助排序键 - 在 BigQuery 或 Snowflake 中，
RANGE对TIMESTAMP的支持更鲁棒；但在 SQLite 或旧版 Hive 上，基本只能退回到ROWS+ 自连接模拟 - 别试图用
RANGE实现“自然日”窗口（如“今天 00:00 到现在”），它不识别日期边界，得靠WHERE或子查询预过滤
PostgreSQL 中写对 RANGE BETWEEN 的三个硬性条件
缺一不可，否则语句合法但结果错得离谱。
- 窗口定义里必须显式写
ORDER BY，且只能有一个排序表达式（不支持ORDER BY a ASC, b DESC） - 排序列类型必须支持减法运算：数值型可直接用
RANGE BETWEEN 10 PRECEDING，时间型必须配INTERVAL，如RANGE BETWEEN INTERVAL '30' MINUTE PRECEDING - 不能混用
RANGE和帧内GROUPS（后者是 SQL:2016 新增，PostgreSQL 尚未支持），写了就报ERROR: RANGE frame with GROUPS is not implemented
示例（正确）：
SELECT
event_time,
SUM(amount) OVER (
ORDER BY event_time
RANGE BETWEEN INTERVAL '1' HOUR PRECEDING AND CURRENT ROW
) AS hourly_sum
FROM sales;
MySQL 8.0+ 用 RANGE 做时间窗口的绕行方案
MySQL 不接受 INTERVAL 与 RANGE 共用，所以不能直接写 “过去一小时”。但可以转化：把时间转成 Unix 时间戳整数，再用数值型 RANGE。
- 必须用
UNIX_TIMESTAMP(event_time)，不能用CAST(event_time AS SIGNED)——后者在某些版本会截断微秒，导致窗口偏移 - 写成
RANGE BETWEEN 3600 PRECEDING AND CURRENT ROW，单位是秒；若需分钟级，就用60、300等 - 注意时区：
UNIX_TIMESTAMP()默认用会话时区，如果数据存的是 UTC，但会话是 CST，结果会偏差 6 或 7 小时
示例（MySQL）：
SELECT
event_time,
SUM(amount) OVER (
ORDER BY UNIX_TIMESTAMP(event_time)
RANGE BETWEEN 3600 PRECEDING AND CURRENT ROW
) AS hourly_sum
FROM sales;
时间窗口的“固定”不在于语法多漂亮，而在于你是否控制住了排序列的粒度、时区、重复性和类型转换路径。这些地方错一点，结果就漂一小时。 
