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字段（尤其是时间列）建了索引，且类型匹配（DATETIMEvsTIMESTAMP） - 别在外部套
WHERE event_time > NOW() - INTERVAL '5 MINUTE'：优化器通常无法下推，窗口仍会先算全量再过滤 - 高并发实时看板中，
LAG()类函数若没显式帧子句，也会默认用UNBOUNDED PRECEDING，导致内存暴涨
滑动窗口真正生效的前提，从来不是语法写对了，而是 ORDER BY 所依赖的顺序本身足够确定、高效、可预测。时间字段重复、NULL 处理模糊、缺少索引——这些底层细节出问题，上层窗口逻辑再漂亮也没用。
