用ROW_NUMBER()与排序字段做差生成稳定锚点是识别连续区间最可靠方法；孤岛则优先用LEAD()查相邻差值，因LAG()或自连接在时分秒精度、重复值、排序不稳定时易误判，且需显式处理分区、时间截断和业务连续性定义。
直接结论：用 ROW_NUMBER() 与排序字段做差生成稳定锚点，是识别连续区间（Islands）最可靠、兼容性最好的方法；孤岛（Gaps）则优先用 LEAD() 查相邻差值。
为什么不能只靠 LAG() 或自连接判断连续？
很多人一上来就写 LAG(event_date) 算差值，再 CASE WHEN event_date - prev_date > INTERVAL '1 day' THEN 1 ELSE 0 END，这在时间戳含时分秒、或存在重复时间时极易误判——同一天多次事件会因毫秒差异被当成“断开”，而批量导入的重复 event_time 又会让 ORDER BY 不稳定，导致 LAG() 返回错行。
真正要识别“连续区间”，关键不是看两行之间有没有断，而是看哪些行属于同一逻辑段。这个段必须满足：内部相邻差恒定（如日期差为1天、ID差为1），且段间跳跃不等价于单次差值。
- 用
ROW_NUMBER() OVER (ORDER BY event_date)生成严格递增序号，它不依赖实际值，只依赖排序结果 - 对日期型字段，用
DATE(event_date) - ROW_NUMBER() OVER (...)::INT（PostgreSQL）或DATE_SUB(DATE(event_date), INTERVAL ROW_NUMBER() OVER (...) DAY)（MySQL）构造锚点grp - 对整数型字段（如
seq_id），直接seq_id - ROW_NUMBER() OVER (ORDER BY seq_id)即可 - 锚点相同的所有行，就属于同一个连续段；
GROUP BY grp后取MIN()/MAX()就是区间边界
LEAD() 比子查询更稳地查孤岛（Gaps）
查缺失值（比如 ID 序列中跳过了 4、7、9），传统自连接写法性能差、嵌套深，且在大表上容易超时。用 LEAD() 是现代 PostgreSQL 的标准解法：
假设表 t 有单调递增的 value 字段，执行：
SELECT value + 1 AS gap_start, LEAD(value) OVER (ORDER BY value) - 1 AS gap_end FROM t WHERE LEAD(value) OVER (ORDER BY value) - value > 1;
注意三点：
-
LEAD(value)必须和WHERE中的条件保持一致的ORDER BY，否则窗口错位 - 首行的
LEAD()返回NULL，所以NULL - value结果为NULL，自然被WHERE过滤，无需额外处理 - 如果原始数据含
NULL值，ORDER BY value会让NULL排最前，干扰差值计算——务必加WHERE value IS NOT NULL
分区（PARTITION BY）漏写会导致跨组混算
业务上常需按用户、设备、服务名分组统计连续行为，比如“每个用户的最长连续登录天数”。此时 PARTITION BY user_id 是强制项，漏掉就会把用户 A 的最后一条和用户 B 的第一条连起来算，生成完全错误的 grp 锚点。
验证是否漏分区的小技巧：在子查询里加一列 COUNT(*) OVER (PARTITION BY user_id) 和 COUNT(*) OVER () 对比，若两者不等，说明分区已生效；若相等，大概率漏了 PARTITION BY。
另外，当排序字段不唯一（如多条记录同一天、同一秒），仅 ORDER BY event_time 不足以保证窗口函数行为确定。必须补上唯一列：ORDER BY event_time, event_id，否则 ROW_NUMBER() 分配可能每次执行都不一样。
连续性定义必须前置明确，窗口函数不替你做业务判断
窗口函数只是工具，它不会自动知道“连续登录”是指间隔 ≤5 分钟，还是 ≤24 小时；也不会区分“连续订单 ID”和“连续支付金额”。所有阈值、单位、去重逻辑、时间截断（DATE() 还是 TIMESTAMP）都得你在 SELECT 或子查询里显式写死。
最容易被忽略的是时间精度处理：如果原始字段是 TIMESTAMP WITH TIME ZONE，但业务只认“日期连续”，就必须先 DATE(event_time) 再参与计算，否则 '2023-10-01 23:59:59' 和 '2023-10-02 00:00:01' 的差是 2 秒，远小于 1 天，会被误判为连续。
