必须显式声明partition by dept_id和order by sale_date，否则跨部门累加错乱；推荐写法为sum(amount) over(partition by dept_id order by sale_date rows unbounded preceding)，并用coalesce处理null。
OVER子句必须配合PARTITION BY才能按部门分组累计
直接写 OVER(ORDER BY sale_date) 会跨部门累加，结果完全错乱。真正按部门累计，PARTITION BY dept_id 是硬性前提，它把数据先切分成若干独立窗口，每个部门内部再单独排序和累积。
常见错误是漏掉 PARTITION BY，只留 ORDER BY，导致销售数据在所有部门间“串流”。比如市场部最后一天的累计值可能包含技术部前几周的销售额。
-
PARTITION BY dept_id定义窗口边界（部门内独立计算） -
ORDER BY sale_date决定累计顺序（按时间递增） - 两者缺一不可，顺序无关，但语义上建议先写
PARTITION BY
SUM() OVER 的 ORDER BY 必须明确排序字段，否则累计无意义
如果只写 ORDER BY dept_id 或用 ORDER BY NULL，SQL 引擎无法确定行序，多数数据库（如 PostgreSQL、SQL Server）会报错；MySQL 8.0+ 虽允许，但累计结果是未定义的——可能每次执行都不一样。
实际业务中，累计销售额天然依赖时间维度，所以 ORDER BY sale_date 是最常用选择。若存在同天多笔订单，建议补上二级排序，例如 ORDER BY sale_date, order_id，避免因隐式排序导致结果不稳定。
- 不指定
ORDER BY：窗口函数退化为普通聚合，SUM() OVER()等价于全表总和 - 仅
ORDER BY dept_id：逻辑矛盾（分区已按 dept_id 切分，再按它排序无变化） - 推荐写法：
SUM(amount) OVER(PARTITION BY dept_id ORDER BY sale_date ROWS UNBOUNDED PRECEDING)
注意默认窗口帧（frame）在不同数据库的行为差异
MySQL 8.0+ 和 PostgreSQL 默认使用 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，符合累计预期；但 SQL Server 默认是 RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，当 ORDER BY 字段有重复值（如同一天多个订单），RANGE 会把所有同值行一起纳入当前行的累计范围，造成重复累加。
为确保行为一致且可预测，显式声明帧更稳妥，尤其涉及时间类累计时：
- 严格按行序累计（推荐）：
ROWS UNBOUNDED PRECEDING - 避免
RANGE带来的歧义，除非你明确需要“同日期全部计入” - 示例完整写法：
SUM(amount) OVER(PARTITION BY dept_id ORDER BY sale_date ROWS UNBOUNDED PRECEDING)
累计值为 NULL 时需检查原始 amount 是否含 NULL
SUM() 遇到 NULL 会跳过，但若某部门首条记录的 amount 就是 NULL，对应累计值也会是 NULL，后续非空值累计仍正常。这不是窗口函数的问题，而是数据本身质量导致的“断点”。
排查时别急着改 OVER 写法，先确认：SELECT dept_id, sale_date, amount FROM sales WHERE amount IS NULL LIMIT 5;。业务上通常应将 NULL 视为 0，可用 COALESCE(amount, 0) 包裹。
- 错误归因典型表现：看到某部门第一条累计为
NULL，就怀疑PARTITION BY没生效 - 正确做法：先查原始数据，再决定是否用
COALESCE或清洗源头 - 修正后写法：
SUM(COALESCE(amount, 0)) OVER(...)
PARTITION BY 缺失、ORDER BY 模糊、窗口帧隐式差异、以及 NULL 处理这四点，任何一个没对齐业务含义，结果就会静默出错。
