动态滚动时间窗口指窗口边界随每行业务时间自动伸缩（如“过去7天销售额”），必须用RANGE BETWEEN INTERVAL实现；而普通窗口函数默认按物理行序（ROWS）计算，无法适应时间不均匀分布，易导致时间跨度错误。
什么是动态滚动时间窗口，和普通窗口函数有什么区别？
普通窗口函数（如 ROW_NUMBER()、SUM() OVER (ORDER BY ...)）默认按行序（ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW）或固定行数滑动；而「动态滚动时间窗口」要求窗口边界随每行的业务时间（比如 order_time）自动伸缩——例如“过去7天内所有订单金额总和”，不能靠 ROWS 7 PRECEDING，因为数据在时间上不均匀分布。
用 RANGE BETWEEN INTERVAL '7 days' PRECEDING AND CURRENT ROW 实现时间窗口
PostgreSQL、Snowflake、BigQuery（标准SQL模式）、Doris 等支持 RANGE + INTERVAL 的引擎可以直接写时间范围。关键是：必须确保 ORDER BY 的列是 TIMESTAMP 或 DATE 类型，且不能有重复值（否则 RANGE 可能合并多行导致结果偏大）。
常见错误现象：Window frame RANGE PRECEDING is only supported with single ORDER BY column of type TIMESTAMP or DATE —— 这说明你用了字符串时间、整数时间戳，或 ORDER BY 包含了多个字段。
- 正确写法（以 PostgreSQL 为例）：
SELECT order_id, order_time, SUM(amount) OVER ( ORDER BY order_time RANGE BETWEEN INTERVAL '7 days' PRECEDING AND CURRENT ROW ) AS rolling_7d_sum FROM orders; - MySQL 8.0+ 不支持
INTERVAL在RANGE中，得用自连接或LATERAL模拟 - Spark SQL 和 Hive 需用
rangeBetween配合unix_timestamp转为秒数再计算偏移，不能直接写'7 days'
MySQL 里没有 RANGE INTERVAL 怎么办？
MySQL 8.0 支持窗口函数但不支持时间单位的 RANGE，只能退回到基于时间条件的关联方式。性能差但语义准确，适合中小数据量（百万行以内）。
核心思路：对每一行，用 LATERAL（或老式 JOIN + 子查询）拉取其 order_time - INTERVAL 7 DAY 到 order_time 之间的记录聚合。
- MySQL 8.0+ 推荐写法（
LATERAL）：SELECT o1.order_id, o1.order_time, t.sum_amount AS rolling_7d_sum FROM orders o1 LATERAL ( SELECT SUM(o2.amount) AS sum_amount FROM orders o2 WHERE o2.order_time BETWEEN o1.order_time - INTERVAL 7 DAY AND o1.order_time ) t;
- 注意：必须给
order_time加索引，否则全表扫描代价爆炸 - 如果数据稀疏（比如每天只有几条），可先用
DATE(order_time)分组预聚合，再做窗口，避免逐行子查询
为什么不能用 ROWS BETWEEN 6 PRECEDING AND CURRENT ROW 代替？
因为 ROWS 数的是物理行数，不是时间跨度。假设某天没订单，下一天突然来100单，那第100单的窗口会包含前6行（可能全是同一天的数据），完全丢失“过去7天”的业务含义。
更隐蔽的问题：排序字段含重复时间戳时，ROWS 行为不可控（不同引擎处理相同时间戳的顺序可能不同），而 RANGE 会把同时间戳的行视为同一“点”，逻辑更稳定。
真正要兼顾性能和语义时，别只盯着窗口函数本身——先确认你的数据时间分布是否均匀，再决定是用原生 RANGE、模拟 LATERAL，还是预计算每日快照加 ROWS 回溯。
