不加ORDER BY时窗口函数无确定行序，因数据库依赖未定义的物理扫描顺序，导致ROW_NUMBER()等结果不可复现；ORDER BY是窗口计算的锚点，决定帧边界与累计逻辑。

不加 ORDER BY 的窗口函数结果不可预测，不是“乱序”，而是根本没定义顺序。

为什么没 ORDER BY 就算不出稳定行号？

窗口函数如 ROW_NUMBER()、RANK()、SUM() OVER() 都需要一个明确的行处理序列。没有 ORDER BY，数据库就不知道“当前行”是谁、“前一行”在哪——它只能按底层扫描顺序（比如磁盘块读取顺序、索引叶节点遍历顺序）临时编排，而这个顺序：
• 可能随查询并发度变化
• 可能因索引重建或统计信息更新而改变
• 在 MySQL 8.0 和 PostgreSQL 中表现完全不同
• 同一语句执行两次，ROW_NUMBER() 值可能全错位

常见错误写法：ROW_NUMBER() OVER (PARTITION BY dept_id) —— 缺少 ORDER BY，语法虽通过，但编号完全不可复现。

ORDER BY 不只是“排序”，它定义了窗口帧起点

OVER 子句里的 ORDER BY 不是为最终输出服务的，它是窗口计算的锚点。它的存在直接决定默认窗口范围：

• 有 ORDER BY date → 默认窗口是 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW（累计到当前行）
• 没 ORDER BY → 默认窗口是 ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING（整个分区全量）

这意味着：
• SUM(sales) OVER (PARTITION BY region) 每行都显示该 region 总和
• SUM(sales) OVER (PARTITION BY region ORDER BY date) 每行显示“截至当天”的累计值
两者语义完全不同，不是“加个排序更整齐”，而是“换了计算逻辑”。

ORDER BY 字段不唯一，结果照样不稳定

写了 ORDER BY created_at 还是发现 ROW_NUMBER() 每次运行结果不同？大概率是 created_at 有重复值。数据库对同值行的相对顺序不做保证，尤其在并行执行时。

安全做法是补唯一键：

• ORDER BY created_at DESC, id DESC（MySQL / PostgreSQL）
• ORDER BY created_at DESC, event_id（确保每行可精确定位）

别依赖 ORDER BY (SELECT NULL) 或空 ORDER BY，这在 MySQL 8.0+ 会报错，在 PostgreSQL 中行为未定义。

末尾的 ORDER BY 不影响窗口函数计算结果

很多人以为加了查询末尾的 ORDER BY id 就能“修正”窗口编号，其实不行。SQL 执行顺序是：
1. FROM / JOIN → 2. WHERE → 3. GROUP BY → 4. 窗口函数计算（此时只看 OVER 里的 ORDER BY） → 5. SELECT 列生成 → 6. 最后才执行查询级 ORDER BY

所以：
• ROW_NUMBER() OVER (ORDER BY name) 算出来的序号永远按 name 排
• 即使你最后写 ORDER BY id，序号不会重算，只是显示顺序变了
• 调试时务必先去掉末尾 ORDER BY，确认窗口逻辑本身是否正确

最易被忽略的一点：当你用 COUNT(*) OVER () 这种“空窗口”时，某些引擎（如 PostgreSQL）仍会触发隐式全表排序，哪怕你没写 ORDER BY——因为它要确保聚合结果与后续窗口函数的排序锚点一致。这不是 bug，是实现机制决定的。