核心思路是用LAG()识别值变化点生成标志位，再用SUM()累积求和为每段连续值分配唯一组号；关键在于显式比对相邻行而非依赖排序唯一性。
怎么用 LAG() 和 SUM() 构造连续段标记
核心思路是：先识别当前行与上一行的值是否变化，再对“变化点”做累积求和，从而为每一段连续值分配唯一组号。关键不在于分组本身，而在于如何让连续块拥有相同 ID。
常见错误是直接对目标字段用 ROW_NUMBER() 或 RANK()，这只能排序，无法感知“连续性”。必须引入状态变化信号。
- 用
LAG(value) OVER (ORDER BY time_col)获取前一行的值（注意必须显式指定ORDER BY，否则窗口无序） - 构造布尔标记：
CASE WHEN value = LAG(value) OVER (...) THEN 0 ELSE 1 END - 对该标记做累计和：
SUM(flag) OVER (ORDER BY time_col)—— 这就是每个连续段的唯一组号
为什么不能只用 ROW_NUMBER() 做差值法
差值法（如 ROW_NUMBER() - ROW_NUMBER() OVER (PARTITION BY value ORDER BY ...)）在多数场景下可行，但隐含一个危险假设：数据在物理或逻辑上已严格按时间/顺序排列且无重复排序键。
一旦 ORDER BY 子句中存在并列（例如多个记录有相同时间戳），ROW_NUMBER() 的分配顺序由数据库自行决定，导致同一连续段被拆成多组。
- 安全做法是先用
LAG()显式比对相邻值，不依赖排序键唯一性 - 若必须用差值法，请确保
ORDER BY中包含唯一列（如主键）：ORDER BY time_col, id - PostgreSQL 和 SQL Server 对并列排序行为更可控；MySQL 8.0+ 在
ORDER BY未唯一时结果不稳定
GROUP BY 后统计连续长度要注意什么
拿到连续段标记（比如叫 grp_id）后，常规 GROUP BY grp_id, value 即可聚合。但容易忽略两点：
- 必须同时
GROUP BY value，否则不同值可能被错误归到同一grp_id（因为grp_id是按值变化生成的，不同值的段不会重叠，但语义上需显式保留） - 连续长度不是
COUNT(*)就完事——要确认是否需要包含首尾，尤其当原始数据有空值或过滤条件时；建议加MIN(time_col)和MAX(time_col)辅助验证 - 若需只返回最长连续段，不要在外部用
LIMIT 1，而应在子查询中用QUALIFY ROW_NUMBER() OVER (ORDER BY COUNT(*) DESC) = 1（支持该语法的引擎）或嵌套MAX(COUNT(*))比较
实际例子：统计用户连续登录天数
假设表 user_login 有 user_id、login_date，目标是算出每个用户最长连续登录天数。
SELECT user_id, MAX(consecutive_days) AS max_streak
FROM (
SELECT user_id,
SUM(is_new_streak) OVER (PARTITION BY user_id ORDER BY login_date) AS streak_grp,
COUNT(*) AS consecutive_days
FROM (
SELECT user_id,
login_date,
CASE
WHEN LAG(login_date) OVER (PARTITION BY user_id ORDER BY login_date)
= DATE_SUB(login_date, INTERVAL 1 DAY)
THEN 0 ELSE 1
END AS is_new_streak
FROM user_login
) t1
GROUP BY user_id, streak_grp
) t2
GROUP BY user_id;这里的关键细节：用 DATE_SUB 判断是否“昨天登录”，而不是简单比对日期值是否相等；PARTITION BY user_id 防止跨用户污染；内层 GROUP BY 必须包含 streak_grp 才能正确计数。
连续性判断永远依赖上下文含义——是“时间连续”“序号连续”还是“值不变”，写法会完全不同，不能套模板。
