SUM(amount) OVER() 不加 ORDER BY 时默认按 ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING 计算整表总和，导致每行结果相同；必须加 ORDER BY 才能实现逐行累计，且需注意重复值、NULL、索引及类型溢出等问题。
SQL Server 里用 SUM() OVER() 做累计求和，必须写 ORDER BY，否则每行都显示总和，不是累计。
为什么 SUM(amount) OVER() 不加 ORDER BY 就不对
SQL Server 把不带 ORDER BY 的窗口视为“无序分区”，默认按 ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING 计算——也就是整张表加总。结果是每行的累计值都一样，看着像“全表总和复读机”。这不是 bug，是标准行为。
- 错误写法：
SUM(amount) OVER(PARTITION BY user_id)→ 每个用户只显示自己全部 amount 的总和，不是逐笔累加 - 正确前提：只要想“从第一行加到当前行”，
ORDER BY就不可省略，哪怕只是按主键排：ORDER BY id - 业务语义优先：如果字段是
order_date，就别用id替代——SQL Server 不保证自增 ID 和业务时序严格一致
ORDER BY 字段有重复值，累计值会“跳变”
当多行 order_date 相同（比如同一天多笔订单），SQL Server 默认把它们当作“同一排序位置”，SUM() OVER() 会一次性把这批行的 amount 全加进第一行的累计值里，后续行直接继承该值，中间没有递增过程——看起来就是“跳了一大截”。
- 典型现象：2026-05-01 有 3 笔订单，金额分别是 100、200、300；累计列显示为 600、600、600，而不是 100、300、600
- 解决办法：在
ORDER BY后追加唯一字段，例如ORDER BY order_date, order_id - 不要用
RANK()或DENSE_RANK()做二级排序——它们仍会产生并列序号，无法消除歧义；ROW_NUMBER()更稳，但代价是多一次计算
分组内累计必须 PARTITION BY + ORDER BY 同时存在
只写 PARTITION BY user_id 不够，SQL Server 会警告或返回非确定性结果。它需要知道“每个用户内部按什么顺序累加”。漏掉 ORDER BY，等价于让用户自己猜顺序，两次执行可能得到两套不同累计值。
- 正确写法：
SUM(amount) OVER(PARTITION BY user_id ORDER BY order_date, order_id) - 注意 NULL 处理：SQL Server 默认
NULLS FIRST，如果order_date有空值，它们会挤在最前面，导致首几行累计异常；稳妥做法是用ISNULL(order_date, '1970-01-01')或CASE WHEN order_date IS NULL THEN '1970-01-01' ELSE order_date END统一兜底 - 不能在同一个查询里混用聚合和窗口：比如
SELECT user_id, SUM(amount), SUM(amount) OVER(...)会报错，除非加GROUP BY user_id，但那样窗口函数是在聚合后执行，ORDER BY order_date已失效
累计结果不能在 WHERE 或 HAVING 里直接过滤
窗口函数的执行时机晚于 WHERE，所以 WHERE cum_amount > 1000 会报错：“Invalid column name 'cum_amount'”。这是 SQL Server 的执行逻辑决定的，不是语法问题。
- 必须用 CTE 或子查询包裹：
WITH t AS (SELECT *, SUM(amount) OVER(...) AS cum_amount FROM orders) SELECT * FROM t WHERE cum_amount > 1000 - 别在
ORDER BY外层再写一遍ORDER BY：比如外部ORDER BY order_date和窗口里的ORDER BY order_date同时存在，可能触发优化器误判，导致累计值错位 - 如果原始
amount是INT且数据量大，累计过程中可能溢出（SQL Server 报Arithmetic overflow error）；提前转类型：SUM(CAST(amount AS BIGINT)) OVER(...)
最易被忽略的一点：SQL Server 对 ORDER BY 字段的索引敏感。没索引时，大表上 SUM() OVER() 可能慢几倍——尤其当 PARTITION BY 和 ORDER BY 是两个不同字段时，建议建联合索引，比如 (user_id, order_date, order_id)。
