ORDER BY 是窗口函数累计计算的前提，决定帧边界和排序锚点；不加时SUM() OVER()对全分区求和，加后按行推进累计，需确保排序字段唯一以避免结果不稳定。
ORDER BY 决定累计范围的边界
不加 ORDER BY 时，SUM() OVER() 默认对整个分区（或全表）求和，每行结果都一样；加上 ORDER BY 后，窗口函数才开始“逐行推进”，默认按 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW 计算——也就是从分区第一行累加到当前行。
常见错误现象：明明写了 ORDER BY date，但累计值跳变或重复，往往是因为 date 不唯一，导致排序不稳定，SQL 引擎自由决定同值行的先后顺序，进而影响累计路径。
- 必须确保
ORDER BY字段组合能唯一确定每一行（例如加id作为第二排序键） - 如果只用非唯一字段（如
date），不同数据库执行结果可能不一致，尤其在分页或重跑时 -
ORDER BY是窗口帧（frame）生效的前提；没有它，ROWS或RANGE子句会被忽略
ORDER BY 与 ROWS/RANGE 的配合差异
ORDER BY 本身不定义窗口大小，它只是为 ROWS 或 RANGE 提供排序锚点。两者行为完全不同：
-
ROWS BETWEEN 1 PRECEDING AND CURRENT ROW：物理行偏移，取前一行 + 当前行，不管值是否接近 -
RANGE BETWEEN INTERVAL '1 DAY' PRECEDING AND CURRENT ROW（PostgreSQL/Oracle）或RANGE BETWEEN 1 PRECEDING AND CURRENT ROW（SQL Server）：按排序字段的值做逻辑范围，比如金额相差 ≤1 的所有行 - 若排序字段是
salary，RANGE BETWEEN 100 PRECEDING AND CURRENT ROW会把所有salary在[current_salary - 100, current_salary]区间内的行纳入求和
错误示例：SUM(amount) OVER (ORDER BY date ROWS BETWEEN 1 PRECEDING AND CURRENT ROW) 在日期有重复时，可能把同一天多笔记录全算进“前一行”，实际变成“当天所有记录 + 前一天最后一笔”——这不是你想要的移动窗口。
ORDER BY 升序 vs 降序改变累计方向
默认 ASC 是正向累计（从头加到当前）；显式写 DESC 就变成反向累计（从末尾倒加到当前）：
-
SUM(sales) OVER (ORDER BY date ASC)→ 截至当天的总和 -
SUM(sales) OVER (ORDER BY date DESC)→ 从最后一天起，累计到当前行（即“剩余未完成量”类场景） - 注意：
DESC不影响UNBOUNDED PRECEDING的语义——它仍指排序后序列的起点，即最大值所在行
容易被忽略的一点：当你用 ORDER BY date DESC 配合 ROWS BETWEEN CURRENT ROW AND 2 FOLLOWING，实际取的是“当前行 + 后面两行”，但由于排序已反转，这“后面两行”其实是日期更早的两条记录。
PARTITION BY 和 ORDER BY 的执行依赖关系
PARTITION BY 先分组，ORDER BY 再在每个组内排序——顺序不能颠倒。如果漏写 PARTITION BY 却指望按某字段分组累计，结果就是全表乱序累计，不是你预期的“每个用户独立累计”。
- 典型错误：
SUM(amount) OVER (ORDER BY date)用于用户行为表，没加PARTITION BY user_id→ 所有用户混在一起按时间累加 - 正确写法：
SUM(amount) OVER (PARTITION BY user_id ORDER BY event_time) - 性能影响：
ORDER BY字段若无索引，大表上窗口函数会触发全局排序，显著拖慢查询；建议在(user_id, event_time)上建联合索引
最易被忽视的细节：窗口函数执行时机在 WHERE 和 GROUP BY 之后、ORDER BY（外层）之前。这意味着你不能靠外层 ORDER BY 来“修正”窗口内的排序逻辑——窗口内的 ORDER BY 必须写对，否则累计结果不可靠。
