滑窗聚合不能用group by实现，必须用窗口函数如range between interval 'n minutes' preceding and current row；需注意数据库兼容性、时间字段索引、时区统一及精度处理。
GROUP BY 配合时间截断函数做滑窗聚合不成立
直接用 GROUP BY 无法实现真正意义上的“滑动窗口”聚合，它只能做**固定边界分组**（如按小时、按天），窗口之间不重叠。所谓“滑窗”，比如每5分钟滚动计算一次过去30分钟的平均值，这种动态偏移的聚合，SQL标准 GROUP BY 本身不支持。
用窗口函数 OVER (ORDER BY ... RANGE BETWEEN ...) 替代
真正可行的滑窗聚合必须依赖窗口函数，核心是 RANGE BETWEEN INTERVAL '29 minutes' PRECEDING AND CURRENT ROW 这类基于时间范围的定义。不同数据库语法略有差异：
- PostgreSQL 支持
RANGE BETWEEN INTERVAL 'N minutes' PRECEDING AND CURRENT ROW，要求排序字段是TIMESTAMP类型且有索引 - MySQL 8.0+ 仅支持
ROWS，不支持RANGE时间偏移，得用自连接或生成时间序列模拟 - ClickHouse 可用
rangeBetween或neighbor()+ 条件过滤，但需确保时间字段已排序
示例（PostgreSQL）：
SELECT
event_time,
AVG(value) OVER (
ORDER BY event_time
RANGE BETWEEN INTERVAL '29 minutes' PRECEDING AND CURRENT ROW
) AS avg_30min
FROM metrics;
用子查询或 CTE 模拟滑窗时的性能陷阱
当数据库不支持 RANGE 时间窗口时，有人会写自连接：WHERE t2.event_time >= t1.event_time - INTERVAL '29 minutes'。这极易导致全表扫描，尤其在没对 event_time 建索引或数据量大时，执行时间呈 O(n²) 增长。
- 必须为时间字段建立 B-tree 索引：
CREATE INDEX idx_metrics_time ON metrics(event_time); - 避免在
WHERE中对时间字段用函数（如DATE(event_time)），否则索引失效 - 若窗口跨度固定且数据按时间递增写入，可考虑物化视图或定时任务预聚合，而非实时计算
时间精度与时区错位会导致窗口结果漂移
滑窗结果异常，八成是因为时间字段带有时区信息但未统一处理。例如 PostgreSQL 中 TIMESTAMP WITH TIME ZONE 和 TIMESTAMP WITHOUT TIME ZONE 混用，INTERVAL 计算会隐式转换，造成窗口实际覆盖时间偏短或偏长。
- 检查字段类型：
\d table_name看是否为timestamptz - 统一转为 UTC 再计算：
event_time AT TIME ZONE 'UTC' - 确认服务器、会话、字段三处时区设置一致，用
SHOW timezone;验证
滑窗的“滑”字背后全是时间精度和时区细节，漏掉任意一环，聚合结果就不是你想要的那个窗口。
