PostgreSQL、SQL Server（2022+）、Snowflake 和 BigQuery 支持基于时间列的 RANGE BETWEEN INTERVAL '7 days' PRECEDING AND CURRENT ROW 滑动窗口，MySQL 8.0 不支持时间类型 RANGE 计算，需用子查询或 LATERAL 模拟；时间列须为 TIMESTAMP/DATE 类型，联合索引 (customer_id, order_time) 是性能关键。
用窗口函数 OVER 配合 RANGE BETWEEN 实现时间滑动窗口
PostgreSQL、SQL Server（2022+）、Snowflake 和 BigQuery 支持基于时间范围的滑动窗口聚合，核心是把 ORDER BY 字段设为时间列，并用 RANGE BETWEEN INTERVAL '7 days' PRECEDING AND CURRENT ROW 明确时间偏移。MySQL 8.0 不支持 RANGE 对时间类型的计算（只认数值），强行写会报错 Window 'w' with RANGE frame requires ORDER BY to have exactly one expression, of numeric or datetime type，但实际执行时仍可能忽略时间语义、按行号算——结果完全错误。
实操建议：
- 确认数据库版本是否真正支持时间类型
RANGE：查文档或跑SELECT SUM(amount) OVER (ORDER BY order_time RANGE BETWEEN INTERVAL '1 day' PRECEDING AND CURRENT ROW) FROM orders LIMIT 1看是否报错 - 时间列必须是
TIMESTAMP或DATE类型，CHAR或INT存的时间戳（如 Unix 秒）不参与RANGE计算，会被静默转成行偏移 - 如果用
PARTITION BY customer_id，每个客户独立滑动，但注意：同一客户多笔订单在毫秒级时间相同，RANGE会把它们全纳入当前窗口（而非仅“最近7天”），这是设计行为，不是 bug
MySQL 8.0 下绕过 RANGE 限制的可靠写法
MySQL 只接受 ROWS BETWEEN，但“最近7天”不能靠固定行数模拟——订单密度不均，高峰期一行代表几分钟，低谷期一行可能隔几小时。可行方案是自连接 + 时间条件过滤，再用 GROUP BY 模拟窗口，但性能差；更实用的是用 LATERAL（MySQL 8.0.14+）或子查询关联：
SELECT
o1.order_time,
o1.customer_id,
(SELECT SUM(o2.amount)
FROM orders o2
WHERE o2.customer_id = o1.customer_id
AND o2.order_time >= o1.order_time - INTERVAL 7 DAY
AND o2.order_time <= o1.order_time) AS rolling_sum_7d
FROM orders o1;注意点：
- 必须给
(customer_id, order_time)建联合索引，否则全表扫描代价爆炸 - 数据量超 10 万行时，这个写法会明显变慢；若需高频查询，建议预计算到物化视图或定时写入汇总表
-
INTERVAL 7 DAY是闭区间，包含首尾时刻，和RANGE BETWEEN ... AND CURRENT ROW行为一致
处理时区与边界对齐问题
订单时间存的是 UTC，但业务要求按“本地自然日”滚动（比如中国区看过去 7 个自然日），直接用 order_time 会导致窗口跨午夜不准。别改存储格式，用函数对齐：
- PostgreSQL：用
(order_time AT TIME ZONE 'Asia/Shanghai')::DATE转成本地日期，再配合RANGE BETWEEN——但注意，RANGE只认时间类型，不能直接套::DATE，得保留时间精度，改用(order_time AT TIME ZONE 'Asia/Shanghai')后再减去当日零点偏移 - BigQuery：用
TIME(TIMESTAMP_TRUNC(order_time, DAY, 'Asia/Shanghai'))提取本地日粒度，再结合DATE_SUB构造范围 - 关键陷阱：任何
CAST或TRUNC操作若丢失时间精度（如转成DATE），就破坏了RANGE的连续性，窗口会变成离散“按天聚合”，而非平滑滑动
为什么不能用 LAG/LEAD 模拟滑动窗口？
LAG(amount, 1) 只能取前 1 行，LAG(amount, 7) 是 7 行前，不是 7 天前。时间窗口本质是动态行集合，不是固定偏移。有人试图用多个 LAG 手动加总：LAG(amount,1)+LAG(amount,2)+...，这既不可扩展（窗口变 30 天就得写 30 个），又无法处理空值/并发订单/时间重复等真实场景。
真正要警惕的是“看起来能跑通”的伪解法：比如先用 ROW_NUMBER() 排序再 ROWS BETWEEN 6 PRECEDING AND CURRENT ROW，它假设每小时下单 10 单，那 7 天就是 1680 行——但凌晨三点可能只有 1 单，窗口实际覆盖了 7 天零 2 小时，误差越来越大。
时间滑动窗口的复杂点不在语法，而在语义对齐：数据库理解的“7 天”是字面时间长度，而人脑常默认“最近 7 个完整自然日”。这两者不等价，强行混用必然出错。
