“连续非空状态”的累计值需在NULL处重置，正确做法是先用SUM(CASE WHEN val IS NULL THEN 1 ELSE 0 END) OVER (ORDER BY id)生成分组ID，再按该ID分区并窗口求和，而非简单SUM() OVER (ORDER BY ...)。
什么是“连续非空状态”的累计值
这不是简单的 SUM() OVER (ORDER BY ...)。它要求：一旦某行的值为 NULL，累计就中断；后续非空值从头开始累加，而不是跳过 NULL 继续累计。比如数据序列 [1, 2, NULL, 3, 4]，期望结果是 [1, 3, NULL, 3, 7]，而非 [1, 3, NULL, 6, 10]。
用条件分组（GROUP BY 连续段）实现重置累计
核心思路是：先给每段连续非空记录打上唯一组号，再在组内做窗口求和。组号通过「前一行是否为空」的累积变化来构造。
关键操作：LAG() 判断上一行是否为空，SUM() OVER (ORDER BY ...) 累积生成分组 ID：
SELECT
id,
val,
SUM(val) OVER (
PARTITION BY grp
ORDER BY id
ROWS UNBOUNDED PRECEDING
) AS running_sum
FROM (
SELECT *,
SUM(CASE WHEN LAG(val) OVER (ORDER BY id) IS NULL THEN 1 ELSE 0 END)
OVER (ORDER BY id) AS grp
FROM t
) t1;
注意点：
-
LAG(val) IS NULL表示上一行val是空 —— 这标志着新连续段开始（第一行默认上一行为空，所以首段 grp=0） - 实际中更稳妥的做法是用
val IS NULL反向标记断点：SUM(CASE WHEN val IS NULL THEN 1 ELSE 0 END) OVER (ORDER BY id)，再用该和作为分组键（这样每遇到一个NULL，grp 就 +1，所有非空块自然被隔离） - PostgreSQL/SQL Server 支持
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，MySQL 8.0+ 同样适用；但旧版 MySQL 或 SQLite 不支持窗口函数，这条路走不通
处理边界：首行、全空、连续 NULL
上面逻辑对首行友好（LAG() 返回 NULL，触发 grp 增量），但若首行 val 就是 NULL，它会被归入 grp=0 的“空段”，后续第一个非空值会落在 grp=1 段 —— 这符合语义。
需警惕的情况：
- 排序字段
id必须严格递增且无重复，否则LAG()和OVER (ORDER BY ...)行为不可靠 - 若存在多个
NULL连续，它们各自不参与累计，但会把前后非空段切开成不同grp，这是预期行为 - 某些数据库（如 BigQuery）对
NULL在SUM()中自动忽略，无需额外CASE；但若字段是字符串或需要计数，就得改用COUNT(val)并确认是否跳过NULL
替代方案：递归 CTE（仅限支持的数据库）
当窗口函数嵌套太绕、或需兼容更复杂状态（如“连续大于 0”而非仅“非空”），可考虑递归方式。但代价明显：
- PostgreSQL/SQL Server 支持良好；MySQL 8.0+ 也支持，但性能随数据量下降快
- 必须有明确的初始行（
WHERE id = (SELECT MIN(id) FROM t)），且递归深度受限制（如 SQL Server 默认 100 层） - 比起窗口函数方案，可读性和维护性都更低，除非业务逻辑真依赖逐行状态传递（比如“连续3天登录才开始计积分”）
真正卡住多数人的，往往不是语法，而是没想清楚「连续段」到底由什么定义 —— 是按时间戳顺序？按主键？有没有并列相同时间？这些细节一错，LAG() 和分组就全偏了。
