缺少ORDER BY时SUM() OVER()不是累计求和，而是分组总和或全表总和，每行结果相同；ORDER BY定义“当前行”位置，是累计成立的前提，缺之则逻辑失效、结果不可靠。
缺少ORDER BY时SUM() OVER()根本不是累计求和
它算的是分组内总和或全表总和，每行结果都一样——这不是“截至当前行的累加”，而是“复读机式重复输出”。数据库没有顺序锚点，就不知道哪一行该先加、哪一行是“当前”，逻辑上无法构建累计路径。
ORDER BY定义了“当前行”在窗口中的位置
窗口函数默认帧是ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，但CURRENT ROW这个概念只在排序后才有意义。没ORDER BY，数据库无法确定“当前行”相对于其他行的位置，只能退化为静态聚合。
- 写
SUM(amount) OVER (PARTITION BY user_id)→ 每行都是该用户的全部amount之和 - 写
SUM(amount) OVER ()→ 每行都是整张表的amount总和 - PostgreSQL 14+ 会直接报错；MySQL 8.0+ 虽能执行，但结果不可复现
ORDER BY字段重复会导致累计跳变
比如用ORDER BY order_date，但多笔订单同一天，数据库对这些等值行的物理顺序不保证。同一查询反复执行，可能这次第1笔先累加、下次第3笔先累加，导致中间行的累计值忽高忽低。
- 正确做法：
ORDER BY order_date, id或ORDER BY order_date, created_at, order_id - 避免用
name、status这类高重复率字段单独排序 -
NULL值排序行为跨库不一致（MySQL排最前，PostgreSQL排最后），建议用COALESCE(order_date, '1970-01-01')兜底
GROUP BY后套SUM() OVER()也救不了缺ORDER BY的问题
有人想先聚合再开窗，写SELECT date, SUM(sales), SUM(SUM(sales)) OVER (ORDER BY date) GROUP BY date——语法可能通过，但语义已崩：窗口函数作用在聚合后的单行结果上，“当前行”只剩一个日期，累计逻辑彻底丢失。
- 正确路径：用CTE或子查询先产出明细级时间序列，再在该结果集上开窗
- 错误根源：累计必须基于原始行序，而不是聚合后的压缩行
- 老版本MySQL 5.7不支持窗口函数，变量模拟方案在并发下完全不可靠，别硬扛
ORDER BY当成“让结果好看点”的可选项。它其实是累计求和的开关，一关就失效，而且失效得悄无声息——数值看起来像那么回事，但只要数据重排、换库、加索引，结果就可能突变。 
