滑动窗口聚合必须用WINDOW子句，GROUP BY仅支持静态分组；RANGE按时间值计算更准确但兼容性差，MySQL等不支持RANGE INTERVAL；需ORDER BY时间字段并处理重复戳，性能优化关键在过滤下推与物化。
滑动窗口聚合必须用 WINDOW 子句，不能只靠 GROUP BY
GROUP BY 只能做静态分组，比如按天、按小时切片；时序滑动窗口（如“过去7天销售额总和”）要求每条记录都基于其时间戳向前/向后取固定时间范围的数据，必须依赖 WINDOW 子句配合 ORDER BY 和 RANGE/ROWS 定义窗口边界。PostgreSQL、Snowflake、BigQuery、Trino 都支持，但 MySQL 8.0+ 才开始支持标准窗口函数，且 RANGE BETWEEN INTERVAL '7 days' PRECEDING AND CURRENT ROW 这类时间范围语法在 MySQL 中不被允许——它只认 ROWS，得先转成排序序号再近似处理。
用 RANGE 处理时间维度比 ROWS 更准确，但有兼容性陷阱
RANGE 按实际时间值计算窗口（如 RANGE BETWEEN INTERVAL '30 minutes' PRECEDING AND CURRENT ROW），天然适配不等间隔的时序数据；ROWS 则按物理行数（如 ROWS BETWEEN 29 PRECEDING AND CURRENT ROW），假设每分钟一条记录才能等价于30分钟窗口——一旦存在缺失或高频写入，结果就偏移。但问题在于：RANGE + INTERVAL 仅在 PostgreSQL、Snowflake、BigQuery 中稳定可用；SQL Server 只支持 ROWS；而 SQLite 直接不支持 RANGE 时间偏移。所以实际写法要先查清目标数据库是否支持 RANGE BETWEEN INTERVAL：
- PostgreSQL 示例：
SELECT ts, value, SUM(value) OVER ( ORDER BY ts RANGE BETWEEN INTERVAL '1 hour' PRECEDING AND CURRENT ROW ) AS sum_last_hour FROM sensor_data; - MySQL 替代方案（需补全时间序列）：
LAG()+ 自连接或生成时间序列再JOIN，无法直接用窗口函数实现真·时间滑动。
ORDER BY 必须包含时间字段，且不能有重复时间戳（或需额外去重策略）
窗口函数按 ORDER BY 排序后划分窗口，如果多条记录 ts 完全相同，RANGE 会把它们全纳入同一窗口，导致聚合值突增；ROWS 则依赖排序稳定性，不同数据库行为可能不一致。真实场景中传感器打点常出现毫秒级重复或乱序。应对方式包括：
- 在
ORDER BY中追加唯一字段：如ORDER BY ts, event_id，确保排序确定性 - 对原始数据预处理去重：用
ROW_NUMBER() OVER (PARTITION BY ts ORDER BY received_at)留下最新一条 - 使用
ts + INTERVAL '1 microsecond' * row_number()人为错开重复时间戳（仅调试用，不推荐生产）
性能敏感点：时间范围越宽、数据量越大，窗口计算代价越高
滑动窗口不是一次性分组，而是对每一行重新扫描符合条件的历史行，复杂度接近 O(n×w)，其中 w 是平均窗口宽度内的行数。当表有亿级记录、窗口设为“90天”，即使加了 ts 索引，执行计划仍可能走全表扫描。优化关键在两点：
- 强制下推过滤：在
WHERE中先限定时间范围，比如WHERE ts >= NOW() - INTERVAL '90 days'，避免对全表启动窗口计算 - 物化中间结果：对高频查询的滑动指标（如每5分钟滚动均值），用定时任务写入汇总表，而非每次实时算
- 注意分区裁剪：若表按
ts分区，确认查询条件能触发分区剪枝，否则窗口函数可能跨分区拉取大量无效数据
真正难的不是写出语法，是让窗口跑得动——尤其当时间跨度和数据密度同时升高时，数据库的执行器很容易放弃索引选择嵌套循环。
