在数据分析工作中，窗口函数是处理滑动统计的利器。但说到动态时间窗口，很多人会卡在 RANGE 和 ROWS 的选择上。简单来说，RANGE 窗口帧按排序列的值范围（如时间或数值区间）定义窗口，将同值行视为逻辑单元；ROWS 则按物理行号严格计数，逐行滑动。本质区别在于 RANGE 是值域驱动、ROWS 是行号驱动。
什么是 RANGE 窗口帧，和 ROWS 有什么本质区别
RANGE 的核心是按值范围划分窗口边界，而不是按行数。它只对 ORDER BY 列生效，并且该列必须是可排序的数值或时间类型。举个例子，当使用 ORDER BY order_time 时，RANGE BETWEEN INTERVAL '7 days' PRECEDING AND CURRENT ROW 意味着“把当前行时间往前推7天内的所有行都纳入窗口”。即便数据有缺失，或者存在重复的时间点，RANGE 都会忠实地根据时间值来匹配行。相比之下，ROWS 只认物理行数，完全不管时间是否连续。
这里有个常见的坑：在 ORDER BY created_at 后使用 RANGE BETWEEN INTERVAL '1 hour' PRECEDING AND CURRENT ROW，有时会返回空结果。问题往往出在数据类型上。比如在 PostgreSQL 中，如果 created_at 是 TIMESTAMP 类型，可能需要显式转换才能与 INTERVAL 运算；而 MySQL 8.0+ 则直接支持，SQLite 干脆就不支持在窗口帧里用 INTERVAL。
- PostgreSQL：必须写成
RANGE BETWEEN INTERVAL '7 days' PRECEDING AND CURRENT ROW，且ORDER BY列需为TIMESTAMP或DATE类型。 - MySQL 8.0+：支持相同语法，但不允许
INTERVAL和非时间列混用。例如，对INT列使用INTERVAL 100会直接报错。 - SQL Server：完全不支持
INTERVAL语法，只能用RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW这类静态写法。要实现动态时间窗口，通常得靠子查询或 CTE 来模拟。
如何在 PostgreSQL 中正确写出 30 天滚动销售额统计
实现一个30天滚动销售额统计，关键不在于生搬硬套语法，而在于事先确认三件事：时间列的类型、时区是否统一、以及是否需要去重聚合。假设我们有一张 orders 表，时间字段是带时区的 paid_at::TIMESTAMP WITH TIME ZONE，金额字段是 amount，那么查询可以这样写：
SELECT
paid_at,
SUM(amount) OVER (
ORDER BY paid_at
RANGE BETWEEN INTERVAL '30 days' PRECEDING AND CURRENT ROW
) AS rolling_30d_sales
FROM orders
WHERE paid_at IS NOT NULL;
这里有几点需要特别注意：
- 如果
paid_at存在重复值（比如同一秒内有多笔订单），RANGE会把它们全部计入当前窗口，这可能导致图表上出现单秒内的数据突增。这并非 Bug，而是RANGE基于值范围的设计逻辑。 - 窗口函数是在
WHERE子句过滤后的结果集上计算的。如果想排除未来的测试数据，务必在WHERE条件里提前过滤掉。 - 当时区处理混乱时，一个稳妥的做法是先用
paid_at AT TIME ZONE 'UTC'统一转换为 UTC 时间，再进行ORDER BY，这样可以避免本地时区夏令时切换对窗口跨度造成意外影响。
MySQL 8.0 实现动态小时级滑动窗口的限制与绕法
MySQL 8.0 虽然支持 RANGE 配合 INTERVAL 的语法，但限制颇多：它仅适用于 DATETIME 或 TIMESTAMP 类型的列，并且无法用变量直接控制间隔长度。也就是说，你没法直接写出 INTERVAL @window_hours HOUR 这样的动态语句。因此，要实现“用户可配置的 N 小时窗口”，通常需要借助预处理语句或在应用层动态拼接 SQL。
一个典型的安全写法示例如下：
SET @hours = 24;
SET @sql = CONCAT(
'SELECT event_time, COUNT(*) OVER (',
' ORDER BY event_time ',
' RANGE BETWEEN INTERVAL ', @hours, ' HOUR PRECEDING AND CURRENT ROW',
') AS cnt FROM events'
);
PREPARE stmt FROM @sql;
EXECUTE stmt;
在这个过程中，有几个坑容易踩到：
- 试图在窗口定义中直接使用
INTERVAL ? HOUR这样的参数化查询会报错，因为 MySQL 不支持对INTERVAL表达式进行参数化。 - 如果
event_time是用INT存储的秒级时间戳，必须先通过FROM_UNIXTIME(event_time)将其转换为日期时间类型，才能参与RANGE计算，否则语法检查无法通过。 - 对没有索引的列进行
ORDER BY会导致全表排序，在大数据量表上性能堪忧。因此，强烈建议在event_time这类排序列上建立 B-tree 索引。
为什么有些场景必须用 RANGE 而不能用 ROWS
当业务逻辑严格依赖于“真实的时间跨度”而非“物理的记录条数”时，ROWS 就力不从心了。举个监控系统的例子：假设系统每5分钟上报一次指标，但某次网络故障导致连续3小时没有数据上报。如果使用 ROWS BETWEEN 36 PRECEDING AND CURRENT ROW（对应180分钟），由于故障期间没有新行，窗口将无法回溯到故障前最后一条正常数据。而使用 RANGE BETWEEN INTERVAL '3 hours' PRECEDING AND CURRENT ROW，则能准确地抓取到故障时间点前3小时内的所有有效数据点，包括故障前的那一个。
金融领域的 K 线聚合是另一个典型场景。计算日线要求的是“过去24小时内所有的交易 tick 数据”，而不是“最近的1000笔交易”。这时，RANGE 是唯一符合业务语义的选择。
不过，需要清醒认识到的是，RANGE 的性能通常不如 ROWS，尤其是在时间列基数很高的情况下。数据库需要反复进行范围查找，而非简单的顺序扫描。如果数据能保证严格按时间递增且没有重复值，那么使用 ROWS 配合应用层逻辑来处理数据补零，往往在性能和控制力上更胜一筹。
