不是必须，但绝大多数场景下不加order by会导致窗口函数计算顺序不确定；它控制窗口内计算顺序而非最终结果排序，影响row_number()、rank()、lag()、sum() over(order by ...)等依赖行序的函数。
窗口函数里加 ORDER BY 是必须的吗？
不是必须，但绝大多数场景下不加就等于没排序——因为窗口函数默认不保证行序，ORDER BY 在 OVER() 子句里控制的是「窗口内计算的顺序」，不是最终结果集的顺序。
常见错误现象：ROW_NUMBER() 或 RANK() 返回的序号看起来“乱”，其实是没在 OVER() 里指定排序依据，数据库按物理存储顺序或优化器决定的顺序计算，每次执行可能不同。
- 只对分组内排序：用
OVER (PARTITION BY user_id ORDER BY created_at) - 全表逻辑排序（不分组）：用
OVER (ORDER BY score DESC) - 想让最终结果也按某列排？那是外层
ORDER BY的事，和窗口函数里的ORDER BY无关
ORDER BY 在窗口函数中影响哪些函数的行为
只有依赖“位置”或“累积”的函数才真正受 ORDER BY 影响；纯聚合类如 AVG() OVER (PARTITION BY ...) 不加 ORDER BY 也能算，但结果是静态聚合值，不体现滚动特性。
典型受影响函数：
-
ROW_NUMBER()、RANK()、DENSE_RANK()：必须有ORDER BY才有意义 -
LAG()、LEAD()、FIRST_VALUE()、LAST_VALUE()：依赖明确的行序，否则取值不可控 -
SUM() OVER (... ORDER BY ...)、AVG() OVER (... ORDER BY ...)：变成累计计算，不加ORDER BY就是全分区总和/均值
LAST_VALUE() 为什么总返回第一行的值？
这是最常踩的坑：LAST_VALUE(x) OVER (ORDER BY ts) 默认窗口帧是 RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，所以“最后”只是当前行及之前，不是整个分区。
正确做法是显式定义窗口帧：
- 要整个分区最后一行：
LAST_VALUE(x) OVER (PARTITION BY group_id ORDER BY ts ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) - 注意
ROWS比RANGE更可控，尤其当排序字段有重复值时 - MySQL 8.0+ 和 PostgreSQL 支持完整帧语法；SQLite 和旧版 MySQL 可能不支持
UNBOUNDED FOLLOWING，得换思路（比如用子查询 +MAX(ts)关联）
排序字段含 NULL 时怎么办？
NULL 在 ORDER BY 中默认排最前（PostgreSQL）或最后（MySQL），但窗口函数不会报错，只会静默按该规则排序——导致 ROW_NUMBER() 编号、LAG() 取值都偏离预期。
安全写法是统一控制 NULL 位置：
-
ORDER BY status NULLS LAST（PostgreSQL、Oracle、SQL Server 2022+） - MySQL 用
ORDER BY ISNULL(status), status - SQLite 用
ORDER BY status IS NULL, status - 如果业务上
NULL表示“未开始”，而你想把它当最小值处理，就得提前用COALESCE(status, '0000-00-00')填充
ORDER BY 看似简单，但它是唯一能定义“哪一行是第一、哪一行是上一行”的地方；漏掉、写错、或忽略 NULL 和帧边界，结果就容易在测试环境对、线上跑偏。
