order by 是滑动窗口的必要前提，否则数据库无法确定“前一行”与“后一行”，rows between 等帧定义将失效或报错；必须配合显式帧子句（如 rows between 2 preceding and current row）才能实现真正滑动，仅 order by 默认为累积计算。

不写 ORDER BY 就根本没法定义滑动窗口

滑动窗口的本质是“相对于当前行的前后若干行”，这个“前”和“后”必须依赖明确的顺序。没有 ORDER BY，数据库不知道哪行是“前一行”、哪行是“下一行”，ROWS BETWEEN 1 PRECEDING AND CURRENT ROW 这类表达式就完全失去意义——它会直接报错（如 PostgreSQL 报 ERROR: window frame requires an ordering clause），或被静默忽略（MySQL 8.0+ 可能退化为无序聚合，结果不可控）。

写了 ORDER BY 却没写 ROWS/RANGE，默认是累积统计，不是滑动

这是最常踩的坑。比如写 AVG(x) OVER (ORDER BY ts)，看起来像在按时间滑动，实际执行的是 RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW：从分区第一行算到当前行，越往后窗口越大。这不是“最近 3 行”，而是“从开头到今天”的累计均值。

• 必须显式加帧子句：ROWS BETWEEN 2 PRECEDING AND CURRENT ROW 才是真·3 行滑动
• RANGE BETWEEN INTERVAL '3' DAY PRECEDING AND CURRENT ROW 看似按时间滑动，但遇到重复 ts 值会把同一天所有行全拉进来，窗口大小失控
• 时间字段含 NULL 时，PostgreSQL 默认排最前，MySQL 8.0+ 默认排最后，排序结果跨库不一致

ORDER BY 字段重复或不稳定，滑动行为就不可靠

按 event_time 排序，但多条记录时间戳完全相同（比如批量导入、日志合并），此时仅靠 ORDER BY event_time 无法保证物理顺序稳定。ROWS BETWEEN 1 PRECEDING AND CURRENT ROW 可能跳过某些同时间记录，也可能因引擎实现差异把所有同时间行都塞进窗口。

• 解决方法只有一种：补唯一排序键，例如 ORDER BY event_time, id
• 更稳妥的做法是先用 ROW_NUMBER() OVER (ORDER BY event_time, id) 生成确定性序号，再基于该序号做 ROWS 滑动
• 实时场景下，Kafka/Flink 落库的时间戳常有毫秒级抖动，RANGE 容易漏数或重复，一律优先用 ROWS

ORDER BY 字段没索引，滑动窗口一查就卡住

窗口函数执行前，数据库必须对 ORDER BY 字段完成全量排序。如果 event_time 上没索引，而你要查“最近 5 分钟”的滑动均值，引擎就得扫描全表几百万行再排序——QPS 上去就直接拖垮。

• 必须确保 ORDER BY 字段（尤其是时间列）建了索引，且类型匹配（DATETIME vs TIMESTAMP）
• 别在外部套 WHERE event_time > NOW() - INTERVAL '5 MINUTE'：优化器通常无法下推，窗口仍会先算全量再过滤
• 高并发实时看板中，LAG() 类函数若没显式帧子句，也会默认用 UNBOUNDED PRECEDING，导致内存暴涨

滑动窗口真正生效的前提，从来不是语法写对了，而是 ORDER BY 所依赖的顺序本身足够确定、高效、可预测。时间字段重复、NULL 处理模糊、缺少索引——这些底层细节出问题，上层窗口逻辑再漂亮也没用。