在postgresql 14中，sum() over必须显式指定order by，否则默认对整个窗口求和（每行结果相同），无法实现逐行累计；order by需含唯一字段（如sale_date, order_id）以确保排序稳定，且null值需用coalesce处理以防断层。
为什么SUM() OVER的ORDER BY不能省略
在PostgreSQL 14中，SUM() OVER默认是窗口内所有行求和（等价于SUM() OVER ()），不会自动按时间或顺序累计。如果漏写ORDER BY，结果就是每行都显示总销售额，不是累计值。
必须显式指定排序依据，比如销售日期或订单ID，否则窗口函数无法确定“到当前行为止”的范围。
-
ORDER BY sale_date：按日期自然累计，适合日粒度分析 -
ORDER BY order_id：按插入顺序累计，注意order_id需保证单调递增且无跳号 - 避免用
ORDER BY RANDOM()或未索引字段，会导致性能骤降
如何处理同一天多笔销售的累计顺序
当多条记录sale_date相同时，ORDER BY sale_date会产生不确定的累计顺序——PostgreSQL 14不保证相同键值下的行序稳定，可能导致同一SQL多次执行结果不同。
解决方法是在ORDER BY中加入唯一性补充字段：
- 推荐：
ORDER BY sale_date, order_id（假设order_id主键自增） - 次选：
ORDER BY sale_date, ctid（ctid是物理位置标识，但不建议用于业务逻辑） - 禁止仅用
ORDER BY sale_date且未建联合索引，查询可能变慢且结果不可复现
累计求和时NULL值怎么影响结果
SUM() OVER默认会跳过NULL值，但若某行amount为NULL，它不会参与累计，也不会让后续累计中断——下一行仍基于之前非NULL值之和继续累加。
但要注意边界情况：
- 第一行
amount为NULL→ 累计值为NULL，第二行即使有值，也是从自身开始累加（不是0 + value） - 想把
NULL当0处理，必须显式写SUM(COALESCE(amount, 0)) OVER (...) - 若整列全
NULL，最终累计列全为NULL，不是0
实际查询示例与常见错误写法
正确写法（按日期+订单ID累计）：
SELECT
order_id,
sale_date,
amount,
SUM(COALESCE(amount, 0)) OVER (
ORDER BY sale_date, order_id
) AS running_total
FROM sales
ORDER BY sale_date, order_id;
典型错误：
- 漏
COALESCE→ 遇NULL后累计断层 - 只写
ORDER BY sale_date→ 同日多单结果不稳定 - 在
WHERE里过滤后才开窗 → 累计范围被截断（应先开窗再过滤，或把条件放进FILTER子句）
真正难调的往往是排序键的业务语义是否严格匹配“累计发生顺序”，而不是语法本身。
