SQL Server中用SUM() OVER()做累计求和最直接：必须写PARTITION BY loan_id ORDER BY repay_date, id并显式指定ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，否则易因重复日期或版本差异导致累计错乱。
SQL Server里用SUM() OVER()做累计求和最直接
SQL Server没有内置的“累计还款计划”函数，但SUM()配合窗口函数OVER()能干净利落地算出每期累计还款额。关键不是写多复杂，而是排序必须明确——否则累计值会错乱。
常见错误现象：SUM(amount) OVER(ORDER BY date)没加ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，在部分版本（如 SQL Server 2012）可能返回非预期结果；更隐蔽的是日期字段含重复值，导致同日多笔还款被随机排序，累计值跳变。
- 务必显式指定
ORDER BY列，且该列需具备唯一性或搭配ROWS子句兜底 - 若还款日期有重复，建议追加一个唯一字段（如
id）：ORDER BY date, id - 避免用
GETDATE()或SYSDATETIME()作为排序依据——它们不是稳定键
按贷款合同分组计算各笔贷款的独立累计还款
真实场景中，一张还款表常包含多笔贷款（loan_id），此时必须用PARTITION BY隔离计算域。漏掉它会导致所有贷款混在一起累计，数值完全失真。
示例：假设表repayment含字段loan_id、repay_date、amount：
SELECT
loan_id,
repay_date,
amount,
SUM(amount) OVER (
PARTITION BY loan_id
ORDER BY repay_date, id
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
) AS cumulative_amount
FROM repayment;-
PARTITION BY loan_id确保每个合同单独累计 - 排序仍需兼顾唯一性，所以加了
id（假设主键） - 不写
ROWS子句在 SQL Server 2016+ 默认行为相同，但显式写出更安全、可读性更强
累计还款 vs 剩余本金：别混淆逻辑层级
累计还款是事实聚合，剩余本金是业务推导——后者需要初始贷款金额。很多人试图只靠SUM() OVER()一步算出剩余本金，结果出错。
正确做法是两步：先算累计还款，再用初始金额减去它。注意初始金额通常不在还款表里，得从另一张表（如loan）关联进来：
SELECT
r.loan_id,
r.repay_date,
r.amount,
l.principal AS original_principal,
SUM(r.amount) OVER (
PARTITION BY r.loan_id
ORDER BY r.repay_date, r.id
) AS cumulative_paid,
l.principal - SUM(r.amount) OVER (
PARTITION BY r.loan_id
ORDER BY r.repay_date, r.id
) AS remaining_principal
FROM repayment r
JOIN loan l ON r.loan_id = l.id;- 不能把
l.principal放进OVER()子句里——窗口函数只对当前行集操作，不跨表取值 - 如果某笔贷款尚未还款，
SUM() OVER()返回NULL，需用ISNULL()或COALESCE()处理 - 关联前确认
loan_id在两张表中数据类型一致，否则隐式转换可能拖慢性能
性能敏感点：索引怎么建才让累计计算不卡
当还款记录达百万级，SUM() OVER(PARTITION BY ... ORDER BY ...)执行慢，往往不是函数问题，而是缺少合适索引。
核心原则：索引字段顺序必须匹配OVER()中的PARTITION BY和ORDER BY顺序。
- 最优索引：
CREATE INDEX IX_repayment_loan_date_id ON repayment(loan_id, repay_date, id) INCLUDE (amount); - 如果只按日期查某段时间的累计值，可补充单独索引：
CREATE INDEX IX_repayment_date ON repayment(repay_date) INCLUDE (loan_id, amount); - 避免在
repay_date上建单列索引后还加WHERE loan_id = ?——SQL Server很难高效利用
实际执行时，观察执行计划里是否出现“Window Spool”操作，以及其 I/O 成本占比。高的话，优先检查索引覆盖度和顺序匹配度。
