ORDER BY 在窗口函数中不仅控制排序，更决定窗口帧的起点、方向及累积逻辑。默认无 ORDER BY 时为 RANGE BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOwinG；有 ORDER BY 时默认变为 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，ASC/DESC 影响 CURRENT ROW 定位与 PRECEDING/FOLLOWING 语义，尤其在重复值和 RANGE 框架下差异显著。
ORDER BY 在窗口函数中决定累积行为的起点和方向
在 OVER (PARTITION BY ... ORDER BY ...) 中，ORDER BY 不只控制“看起来怎么排”，它直接定义了窗口帧（frame）的计算顺序。没写 ORDER BY 时，默认是 RANGE BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING，即整个分区；但一旦加上 ORDER BY，默认帧就变成 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW —— 这个隐式变化是多数人踩坑的根源。
比如用 SUM(amount) OVER (PARTITION BY user_id ORDER BY created_at)，结果是每个用户按时间正序的累计和；若改成 ORDER BY created_at DESC，累计和就从最新一条开始倒着加，首行就是该用户的总金额，末行等于最新一笔金额。
ASC 和 DESC 对 ROWS / RANGE 帧边界的影响不同
ORDER BY col ASC 和 ORDER BY col DESC 不仅翻转结果顺序，还会让数据库对 CURRENT ROW 的定位、以及 PRECEDING/FOLLOWING 的语义发生偏移。尤其当存在重复值时，RANGE 框架下 ASC 和 DESC 可能给出完全不同的分组聚合结果。
- 使用
ROWS框架时，ORDER BY x DESC下的1 PRECEDING指的是物理上“前一行”（即时间更早或值更大的那行），不是逻辑上“更小的值” - 使用
RANGE框架时，ORDER BY x DESC会让1 PRECEDING匹配值 ≥ 当前行且最接近的那些行（因排序方向改变，等价条件实际反转） - postgresql 允许显式写
ROWS BETWEEN ...覆盖默认行为；mysql 8.0+ 和 SQL Server 同样遵循此规则，但 sqlite 目前不支持自定义帧
常见错误：以为 ORDER BY 只影响输出顺序，忽略其对窗口边界的绑定作用
典型误用：ROW_NUMBER() OVER (PARTITION BY dept ORDER BY salary) 本意是“每部门按薪资从低到高编号”，但如果后续用这个编号做 WHERE rn 取 Top 3，而实际数据里多个员工薪资相同，ROW_NUMBER() 仍会强制给不同序号——此时真正想用的可能是 RANK() 或加二级排序如 ORDER BY salary, emp_id。
另一个高频陷阱是混用 ORDER BY DESC 和 LAG()：LAG(sales) OVER (ORDER BY date DESC) 返回的是“后一天”的销售额（因为排序倒了，LAG 向“未排序前的上一行”取值，现在那行其实是更早日期），不是“前一天”。要拿前一天，必须保持 ORDER BY date ASC。
验证排序方向影响的最快方法：用 ROWS 显式限定并观察 CURRENT ROW 位置
不要依赖默认帧。调试时直接写出完整子句，例如：
SELECT id, amount, SUM(amount) OVER ( PARTITION BY user_id ORDER BY created_at DESC ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING ) AS remaining_total FROM orders;这样能清晰看出：当前行是“最新订单”，remaining_total 是从它开始往更早订单累加的结果。如果业务语义是“剩余待处理金额”，这个写法才对；若写成 UNBOUNDED PRECEDING，反而会把所有历史订单都算进去。
真正容易被忽略的是：同一套数据、同一个窗口函数，只改 ASC/DESC，不仅结果数值变，连 NULL 出现位置、LEAD/LAG 的跨行引用目标、甚至执行计划里的排序物化方式都可能不同——尤其在大表 + 多层嵌套窗口时，方向选错会导致性能断崖式下降。