动态时间窗口是对每行以自身时间为基准滑动计算（如过去7天），行数不变；GROUP BY则按固定字段静态分组压缩为单行，无法实现时序滑动聚合。
什么是动态时间窗口，和普通 GROUP BY 有啥区别
普通 GROUP BY 按固定字段或截断后的时间（比如 DATE(created_at)）分组，窗口是静态、对齐的。动态时间窗口指的是：对每条记录，以它自身时间为起点（或终点），往前/往后取一段持续时间（如“过去7天”），再在这个滑动区间内聚合——结果行数通常和原始行数一致，不是压缩后的汇总。
这本质不是 GROUP BY 能直接解决的，得靠窗口函数 + 时间范围界定，核心是用 ROWS BETWEEN 或 RANGE BETWEEN，但后者对时间类型支持因数据库而异。
PostgreSQL 中用 RANGE OVER 实现秒级滑动窗口
PostgreSQL 支持 RANGE BETWEEN INTERVAL '7 days' PRECEDING AND CURRENT ROW，前提是排序字段是 TIMESTAMP WITH TIME ZONE 或 TIMESTAMP 类型，且必须用 ORDER BY 显式声明时序。
常见错误现象：
- 报错
ERROR: RANGE is only supported with ORDER BY of a single column：说明ORDER BY写了多个字段，或用了表达式（如ORDER BY created_at::date） - 结果为空或聚合值异常：没处理
NULL时间值，或时区不一致导致跨天偏移
实操建议：
- 确保
ORDER BY字段是原生TIMESTAMP，不要 cast 或运算 - 使用
RANGE（非ROWS），否则窗口按行数算，不是真实时间跨度 - 聚合函数必须是窗口兼容的，如
SUM()、AVG()、COUNT()，不能用GROUP_CONCAT这类非标准函数
SELECT
id,
created_at,
SUM(amount) OVER (
ORDER BY created_at
RANGE BETWEEN INTERVAL '7 days' PRECEDING AND CURRENT ROW
) AS sum_7d
FROM orders;
MySQL 8.0+ 只能靠自连接或 LATERAL 模拟（无原生 RANGE 时间支持）
MySQL 目前（截至 8.0.33）不支持 RANGE BETWEEN INTERVAL，ORDER BY 后只能跟 ROWS，即按物理行数滑动，无法保证时间连续性。强行用 ROWS BETWEEN 6 PRECEDING AND CURRENT ROW 假设每小时1条数据？不可靠。
可行替代方案：
- 用
LATERAL（MySQL 8.0.14+）关联子查询，对每行查出其前7天内的记录再聚合 - 自连接 + 时间条件，但大数据量时性能陡降（
O(n²)） - 预生成时间槽（如每分钟一个 slot），把事件打点到槽中，再用普通
GROUP BY slot_time—— 这是空间换时间，适合实时性要求不高、可接受分钟级延迟的场景
示例（LATERAL）：
SELECT o1.id, o1.created_at, t.sum_7d FROM orders o1 LATERAL ( SELECT SUM(amount) AS sum_7d FROM orders o2 WHERE o2.created_at BETWEEN o1.created_at - INTERVAL 7 DAY AND o1.created_at ) t;
ClickHouse 和 BigQuery 的更简洁写法
ClickHouse 原生支持时间窗口聚合函数：sumIf(amount, created_at >= today() - 7) 不行，但可用 runningAccumulate + arrayJoin 组合模拟；更推荐用 neighbor() 手动维护滑动状态——不过实际中多数人直接走 GROUP BY toStartOfInterval(created_at, INTERVAL 1 day) 配合 WINDOW FUNCTION 插件。
BigQuery 最省事：UNBOUNDED PRECEDING + RANGE BETWEEN 完全支持，且自动处理时区归一化（只要字段是 TIMESTAMP 类型）：
SELECT
id,
created_at,
SUM(amount) OVER (
ORDER BY UNIX_SECONDS(created_at)
RANGE BETWEEN 60 * 60 * 24 * 7 PRECEDING AND CURRENT ROW
) AS sum_7d
FROM `project.dataset.orders`;
注意：BigQuery 要把 TIMESTAMP 转成秒级整数才能用 RANGE，这是它的限制，不是 bug。
时间窗口的“动态”二字，容易让人忽略底层代价：PostgreSQL 的 RANGE 窗口需要索引加速排序，否则每次扫描都是全表；MySQL 的自连接在百万级数据上可能跑几分钟；真正上线前，务必在生产等效数据量下压测执行计划。
