核心思路是用ROW_NUMBER()生成条件内序号和全局序号，二者作差得恒定“连续组键”，相同值即同一连续段；须确保排序字段唯一、CASE WHEN覆盖所有分支、差值列别名规范，并按业务定义严格对齐排序依据。
怎么用 ROW_NUMBER() 和差值法识别连续段
核心思路是：对满足条件的行单独编号，再和全局序号做差——连续段的差值恒定。这不是脑筋急转弯，是窗口函数最稳的破题路径。
常见错误现象：ROW_NUMBER() OVER (ORDER BY id) 直接套在 WHERE 过滤后结果上，导致“断点重排”，连续性被破坏。
- 必须先用
CASE WHEN标记条件是否满足（比如status = 'success'），再对全部数据按时间/ID排序生成全局序号 - 再用
ROW_NUMBER() OVER (PARTITION BY flag ORDER BY id)生成条件内序号——注意PARTITION BY是标记列，不是原始分组字段 - 两序号相减得到“连续组键”，相同值即为同一连续段
LAG() 能不能直接判断前一行状态
能，但只适合单次连续计数（比如“当前行及之前最多连续成功几次”），不适合提取完整连续段信息。
使用场景：实时监控告警中计算“已连续失败 X 次”，不需要回溯整个区间。
-
LAG(status, 1) OVER (ORDER BY ts)只能取上一行，无法知道上上行；要判连续 3 次，就得嵌套三层LAG()，可读性和维护性迅速崩坏 - 若需统计每段长度，仍得回到差值法——
LAG()仅适合布尔型“是否中断”辅助判断 - 性能上，
LAG()单次扫描即可，但复杂逻辑下不如差值法一次成型
GROUP BY 连续组键后聚合出错的典型原因
差值算出来是数字，但若原始数据有空值、重复时间戳或排序字段不唯一，会导致同组键散落、聚合断裂。
错误信息示例：result shows fragmented counts for same consecutive run
- 确保
ORDER BY字段严格唯一，必要时追加主键：ORDER BY ts, id -
CASE WHEN中漏写ELSE 0，会让未命中条件的行变成NULL，参与减法后整行失效 - 差值列别名不要用中文或特殊字符，某些引擎（如 Hive）对别名敏感，影响后续
GROUP BY
MySQL 8.0 / PostgreSQL / SQL Server 兼容性要点
差值法逻辑通用，但具体写法微调——不是语法差异，而是默认行为陷阱。
- MySQL 8.0 支持全部所需窗口函数，但
ROW_NUMBER()排序字段含NULL时，默认排在最前，可能打乱业务顺序 - PostgreSQL 对
ORDER BY中NULLS FIRST/LAST敏感，建议显式声明，例如：ORDER BY ts NULLS LAST - SQL Server 2012+ 支持，但旧版本（如 2008）无窗口函数，只能用自连接或游标，性能差一个数量级
连续性统计真正难的不是写法，而是确认“连续”的业务定义是否和排序依据完全对齐——比如按创建时间排，但实际业务连续性依赖处理时间，字段选错，结果全偏。
