sum() over 的最基本写法是 sum(col) over (order by col)，必须显式指定 order by，否则无法保证累计和的正确性；默认帧 rows unbounded preceding 可省略但建议写出。
SQL Server里SUM OVER的最基本写法长什么样
直接用 SUM() OVER() 就能算累计和，但必须明确排序依据，否则结果不可靠。窗口函数不保证物理顺序，ORDER BY 子句在 OVER 里不是可选的——哪怕你看着数据是按时间排好的，也得显式写出来。
常见错误是漏掉 ORDER BY，比如：SUM(amount) OVER (PARTITION BY customer_id)，这只会返回每个客户总金额的重复值，不是累计值。
正确起步写法：
SELECT order_date, amount, SUM(amount) OVER (ORDER BY order_date ROWS UNBOUNDED PRECEDING) AS running_total FROM orders;
-
ROWS UNBOUNDED PRECEDING是默认帧定义，可以省略，但显式写出更清晰 - 如果
order_date有重复，建议加二级排序，比如ORDER BY order_date, order_id，避免非确定性结果 - 注意：
ORDER BY里的列必须出现在SELECT或ORDER BY子句中（SQL Server 2012+ 允许不在 SELECT 中，但逻辑上应可排序）
按客户分组做累计金额时怎么避免跨客户累加
用 PARTITION BY 切分窗口范围，它像“重置计数器”的开关。没加 PARTITION BY，整个结果集就一个累计序列；加了，每个分区内部独立累计。
典型错误是只写 PARTITION BY customer_id 却忘了 ORDER BY，例如：SUM(amount) OVER (PARTITION BY customer_id) —— 这会把每个客户的总金额填满整列，不是逐笔累计。
正确组合：
SELECT
customer_id,
order_date,
amount,
SUM(amount) OVER (
PARTITION BY customer_id
ORDER BY order_date, order_id
ROWS UNBOUNDED PRECEDING
) AS customer_running_total
FROM orders;
-
PARTITION BY必须和ORDER BY共存才能实现“分组内有序累计” - 若客户有多笔同日期订单，不加
order_id等唯一列，SQL Server 可能任意排序，导致同一日期的累计值顺序不稳定 - 性能上，
PARTITION BY + ORDER BY会触发排序操作，大数据量时注意索引覆盖（如建在(customer_id, order_date, order_id)上）
遇到NULL值或金额为负时累计结果还准不准
SUM() OVER 对 NULL 的处理和普通 SUM() 一致：跳过 NULL，不参与计算。但负值完全合法，会如实计入累计和。
容易被忽略的是：如果某行 amount 是 NULL，它的累计值会等于前一行的累计值（因为当前行没贡献），而不是 NULL。这不是 bug，是窗口帧计算逻辑决定的。
- 想把
NULL当 0 处理？用ISNULL(amount, 0)或COALESCE(amount, 0)包一层 - 想让整行
NULL导致累计值也NULL？目前 SQL Server 不支持跳过帧中某行后中断累计，只能靠外层逻辑控制 - 负金额场景（如退货）天然支持，不需要特殊处理，累计值会自然下降
为什么有时候累计值突然变小或重复，是不是OVER写错了
最常见原因是排序字段存在重复且未提供稳定次序，导致 SQL Server 在不同执行中对相同 ORDER BY 值的行随机排列，累计值“看似错乱”。这不是函数问题，是排序不确定性暴露出来的逻辑漏洞。
另一个隐蔽坑是：在视图或CTE里用了 SUM() OVER，然后外部再 ORDER BY，但窗口计算已在前一步完成，外部排序不会改变累计列的值顺序——累计列永远严格按 OVER 子句里的 ORDER BY 计算。
- 查证是否排序不稳：把
ORDER BY字段和ROW_NUMBER() OVER (...)一起查出来，看重复值对应行号是否浮动 - 别依赖查询结果的显示顺序去反推累计逻辑，始终以
OVER内的ORDER BY为准 - 涉及分页（如
OFFSET-FETCH）时，累计列必须在最内层计算，不能在分页后补算，否则帧范围被截断
