条件累加断点标记是按某列排序后对数值列累计求和，遇特定条件行（如status='break'）时重置累加器；需用count() over构造分组id再partition by实现，断点行是否参与累加取决于case处理。
什么是条件累加断点标记
就是在按某列排序后，对数值列做累计求和，但遇到满足特定条件的行（比如 status = 'break'）时，重置累加器——不是跳过该行，而是“在此处截断并从0重新开始累加”。SUM() OVER 本身不支持动态重置，必须借助分组逻辑间接实现。
用 ROW_NUMBER 和自定义分组 ID 切分连续段
核心思路是：先识别每个“断点”，再给断点前的所有行打上相同组号，最后在组内做 SUM() OVER。关键在于构造稳定的分组标识符（group_id），常用方法是统计到当前行为止的断点数量：
SELECT
id, status, amount,
SUM(amount) OVER (
PARTITION BY grp
ORDER BY id
ROWS UNBOUNDED PRECEDING
) AS running_sum
FROM (
SELECT *,
COUNT(CASE WHEN status = 'break' THEN 1 END)
OVER (ORDER BY id ROWS UNBOUNDED PRECEDING) AS grp
FROM your_table
) t
注意：COUNT(...) OVER 必须用 ROWS UNBOUNDED PRECEDING（不能用 RANGE），否则相同 id 值会引发非预期聚合；grp 是累积断点数，天然把每段连续非断点行归为一组。
断点行要不要参与累加？取决于业务语义
上面写法中，status = 'break' 的行仍被计入 grp 分组（因为 COUNT 包含它），且其 amount 也会进入该组的 SUM。若要求“断点行清零、不参与累加”，需额外处理：
- 用
LAG(status)判断前一行是否为断点，或 - 将断点行的
amount显式置为 0 再计算累加，例如：SUM(CASE WHEN status = 'break' THEN 0 ELSE amount END) OVER (...) - 更稳妥的做法是先用
LEAD/LAG标记每行所属段起始位置，再关联分组
别默认断点行“自动跳过”——SQL Server 不会替你做语义过滤，OVER 子句里的表达式决定一切。
性能与索引注意事项
这类嵌套窗口函数容易触发排序溢出（spill to tempdb），尤其数据量大且 ORDER BY 列无索引时：
- 确保
ORDER BY字段（如id）上有聚集索引或覆盖索引 - 避免在子查询里多次调用同个窗口函数，可提取到 CTE 复用
-
ROWS UNBOUNDED PRECEDING比RANGE更稳定，SQL Server 对RANGE的等值判断在浮点或 NULL 场景下易出错
断点逻辑越复杂（比如多条件组合判断），越要提前物化中间分组结果，否则执行计划可能退化成嵌套循环+逐行计算。
