LAG判断连续的核心是将“连续”定义为数值差（如日期加1天、数字加1），必须配合ORDER BY和PARTITION BY使用，常用ROW_NUMBER()减LAG构造连续组，LAG比LEAD更贴合从前往后的逻辑直觉。
怎么用 LAG 判断当前行和上一行是否连续
核心是把“连续”转化成数值差判断：比如日期连续就是 date = LAG(date) + INTERVAL '1 day'，数字连续就是 num = LAG(num) + 1。窗口函数本身不识别“连续”，得靠你定义好什么叫“连续”。
常见错误是直接 LAG(value) 后不做等值或差值比较，只取值就结束了——那只是拿到上一个值，没形成逻辑判断。
- 必须配合
ORDER BY使用，否则LAG的“上一行”无意义 - 分区字段（
PARTITION BY）漏写会导致跨组污染，比如用户A的最后一条和用户B的第一条被当成连续 -
LAG(col, 1, default_val)第三个参数设默认值能避免首行NULL干扰判断逻辑
ROW_NUMBER() 减 LAG 构造连续组（最常用解法）
这是统计“连续出现次数”的标准套路：给原始数据按顺序编号，再对连续段内编号与自然序号做差，差值相同的即为同一连续块。
例如按 user_id 分组、按 login_date 排序后：
SELECT user_id, login_date,
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY login_date)
- ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY login_date - INTERVAL '1 day' * (ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY login_date) - 1)) AS grp更稳妥写法是先用 LAG 标记断点，再用累计和生成组号：
- 先算
is_new_streak = CASE WHEN login_date != LAG(login_date) + INTERVAL '1 day' THEN 1 ELSE 0 END - 再用
SUM(is_new_streak) OVER (PARTITION BY user_id ORDER BY login_date)得到每段连续区间的唯一标识 - 最后按这个标识
GROUP BY就能统计每段长度
为什么不用 LEAD 而用 LAG？
LAG 更自然：判断“从上一行到当前行是否连续”，比“从当前行到下一行是否连续”更容易组织逻辑，尤其在找连续起始点时。
用 LEAD 容易多出一列冗余信息，还可能因末尾 NULL 导致条件漏判；而 LAG 配合 WHERE 过滤掉首行即可干净切入。
-
LAG关注“已发生的连续”，适合统计已完成段落 -
LEAD关注“将发生的连续”，适合预测或标记断点位置，但统计次数时反而绕路 - 两者性能无差异，选哪个纯看逻辑流向是否顺——多数人顺着时间轴从前往后想，
LAG更贴合直觉
字符串/文本字段连续重复怎么处理？
不能直接比 LAG(text_col) 是否相等就完事——得确认“连续出现”是指相邻行值相同，且中间没夹杂其他值。
典型陷阱是忽略排序稳定性：如果两行文本相同但时间戳一样，ORDER BY text_col 可能导致随机排序，使本不连续的行被误判为连续。
- 必须有确定性排序字段（如自增ID、带毫秒的时间戳），哪怕只是辅助排序：
ORDER BY created_at, id - 若只按文本分组再排，会把所有相同文本全挤一起，失去“连续”本意
- 字符型连续统计建议先转成整型序列（如用
DENSE_RANK()编码），再套用数字连续解法，更稳
连续性不是数据自带属性，是你用窗口函数+业务规则共同定义出来的。最容易被忽略的是排序字段的唯一性和业务含义是否真正支撑“连续”判定——别让 ORDER BY 成了黑盒。
