SQL Server中用SUM()配合ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING可高效计算当前行至分区末尾的向后累计和，需显式ORDER BY（如ASC），不可误用DESC或RANGE，且仅SQL Server 2012+原生支持。
SQL Server里用ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING实现向后累计
直接用SUM()加窗口框架就能算当前行到末尾的累计和，关键在ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING这个范围定义。它明确告诉SQL Server：从当前行开始，一直累加到分区末尾，不依赖排序位置“倒过来”这种取巧方式。
常见错误是写成ORDER BY ... DESC再配UNBOUNDED PRECEDING，看似等价，实际结果可能错——因为窗口框架的起点仍按原始ORDER BY逻辑定位，方向翻转容易混淆行序和累积方向。
- 必须显式指定
ORDER BY子句（即使业务上不关心顺序，也要有确定排序，否则ROWS框架无意义） -
UNBOUNDED FOLLOWING只在ROWS或RANGE框架中有效，不能单独用在OVER()里 - 如果分区（
PARTITION BY）内行数超大，该计算仍是O(n)，但比自连接或子查询快得多
示例：按日期倒序计算剩余销售额累计
假设有一张销售表sales，字段为sale_date、amount，想算“从今天起往后所有日期的销售额总和”，即当前行（某天）到分区结尾的累计：
SELECT
sale_date,
amount,
SUM(amount) OVER (
ORDER BY sale_date ASC
ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING
) AS remaining_total
FROM sales;
注意这里ORDER BY sale_date ASC，不是DESC——因为我们要的是“当前天及之后所有天”，自然顺序升序即可。若误写成DESC，CURRENT ROW AND UNBOUNDED FOLLOWING会指向更早的日期，结果完全相反。
和RANGE框架混用时的陷阱
用RANGE BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING看起来一样，但语义不同：它会把所有ORDER BY值等于当前行的行全纳入计算，包括重复值。而ROWS严格按物理行位置。
- 当
ORDER BY列有重复值（比如多个订单同一天），RANGE会导致同一日期内所有行得到相同累计值，且跳过后续不同日期的行 -
ROWS则逐行推进，哪怕sale_date相同，只要它们是不同物理行，累计值就随行号变化 - 除非明确需要“按值分组累计”，否则一律用
ROWS
性能与兼容性提醒
该语法在SQL Server 2012+完全支持，但UNBOUNDED FOLLOWING在某些旧版ODBC驱动或SSIS组件里可能解析失败，报错类似"Incorrect syntax near 'FOLLOWING'"。
- 确认客户端工具或ETL工具是否识别SQL Server 2012+窗口函数语法
- 若需向下兼容SQL Server 2008，只能用自连接或
CROSS APPLY模拟，性能差一个数量级 - 在大宽表上加多个此类窗口函数时，每个都会独立扫描分区，建议先用CTE过滤必要字段再计算
真正容易被忽略的是ORDER BY和框架方向的耦合关系：不是“越往后越要DESC”，而是“CURRENT ROW + FOLLOWING”天然适配升序场景；反过来想，反而最容易写反。
