SQL Server 2012+可用窗口函数在单条SELECT中完成分摊，关键为正确使用PARTITION BY（如contract_id）、ORDER BY（如billing_month，需防重复值）和ROWS BETWEEN；动态加权分摊需SUM不带ORDER BY求总数，滚动分摊用ROWS BETWEEN限定范围；窗口函数不可用于WHERE或JOIN，须用CTE或子查询。
SQL Server 2012 及以上版本原生支持窗口函数，分摊类逻辑（如按时间权重分摊、按比例动态分配、跨周期滚动分摊）完全可以在单条 SELECT 中完成，无需临时表或游标。关键在于正确组合 PARTITION BY、ORDER BY 和 ROWS BETWEEN，并避开 WHERE 中误用窗口函数的典型错误。
分摊场景必须明确分区与排序维度
分摊不是全局计算，而是有业务边界的：比如“每个合同下的费用按签约后各月天数分摊”“每个客户的历史订单按金额占比分摊到产品线”。不写 PARTITION BY 就等于把全表当一个合同处理，结果必然错。
-
PARTITION BY contract_id是最常见起点，确保分摊只在合同内部发生 - 若需按时间顺序逐期累积（如“截至第N个月已分摊总额”），
ORDER BY billing_month不可省；漏掉会导致SUM() OVER()无序累加，数值随机 - 注意
ORDER BY列必须有确定性排序：如果billing_month有重复值（如多笔同月记录），要补上id或ROW_NUMBER()消除歧义，否则 SQL Server 可能返回非预期的累计顺序
动态权重分摊必须用 ROWS BETWEEN 显式框定范围
固定比例分摊（如“每期均摊 1/12”）直接用 SUM(total_amount) / COUNT(*) OVER (PARTITION BY ...) 即可；但真实业务常需按天数、工作日、系数等动态加权，这时不能只靠 ORDER BY，必须用帧子句锁定参与计算的行集。
- 例如“按签约后各自然月实际天数占总服务期天数的比例分摊”：先用
DATEDIFF(day, start_date, end_date) + 1算总天数，再对每月用DAY(EOMONTH(month))算当月天数，最后用SUM(month_days) OVER (PARTITION BY contract_id)得分母——这个SUM必须不带ORDER BY，否则变成累计天数而非总计 - 若要实现“最近3期滚动分摊率”，就得写
ROWS BETWEEN 2 PRECEDING AND CURRENT ROW，否则默认是UNBOUNDED PRECEDING，越滚越大 - SQL Server 对
RANGE帧支持有限（仅限UNBOUNDED或CURRENT ROW），一律用ROWS更稳妥
避免在 WHERE 或 JOIN 条件中直接引用窗口函数结果
窗口函数在 SQL Server 执行计划中属于 SELECT 阶段，晚于 WHERE 和 JOIN。以下写法会报错：WHERE running_total > 10000 或 ON a.rank = b.rank（其中 rank 是 ROW_NUMBER() OVER(...)）。
- 正确做法是套一层子查询或 CTE：
WITH ranked AS (SELECT *, ROW_NUMBER() OVER (...) AS rn FROM t) SELECT * FROM ranked WHERE rn - 若分摊逻辑本身依赖前序结果（如“本期分摊 = 上期余额 × 利率”），窗口函数无法直接递归，得用
LAG()取上一行值再计算，而不是幻想SUM() OVER (ROWS BETWEEN 1 PRECEDING AND CURRENT ROW)能自动带出余额状态 - 特别警惕
FIRST_VALUE()和LAST_VALUE()：后者默认帧是RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，不是整组末尾，要显式写ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING
性能陷阱：ORDER BY 列缺失索引时开销陡增
窗口函数本身不走索引，但 ORDER BY 子句会触发排序操作。当分摊数据量超 10 万行且 ORDER BY 字段无索引时，SQL Server 很可能选择哈希匹配或大量 tempdb 排序，执行时间从毫秒级跳到秒级。
- 在分摊主键（如
contract_id, billing_month）上建复合索引，顺序必须和PARTITION BY+ORDER BY一致，例如CREATE INDEX IX_contract_month ON sales (contract_id, billing_month) - 避免在
ORDER BY中用表达式，如ORDER BY YEAR(billing_date), MONTH(billing_date)；应提前算好billing_year_month CHAR(6)并索引它 - 测试时用
SET STATISTICS XML ON查看执行计划，确认是否出现Sort算子；若有，且输入行数大，基本就是索引问题
真正难的不是写对语法，而是把业务规则准确映射成窗口的分区边界、排序依据和帧范围——比如“按季度分摊但跨年重置”需要 PARTITION BY YEAR(date), DATEPART(quarter, date)，而“按财年分摊（4月起）”就得用 (MONTH(date) + 8) % 12 + 1 调整月份序号。这些细节不画数据流图很容易漏。
