LAG()比自连接更稳，因其按排序取物理前一行，不依赖ON条件匹配，避免数据缺失、重复或精度不足导致的漏行错配；需建(user_id, date)联合索引并注意NULLS LAST确保排序稳定。
查连续登录/连续日期，为什么LAG()比自连接更稳
因为自连接依赖ON条件匹配“上一天”，一旦数据缺失或时间字段有重复、精度不足，就漏行或错配；LAG()直接按排序取物理前一行，只要ORDER BY确定，结果就确定。
常见错误现象：LEFT JOIN t a ON a.date = b.date - INTERVAL '1 day' 在日期字段含时分秒、或存在多条同天记录时，返回NULL或重复行。
实操建议：
- 用
LAG(date) OVER (PARTITION BY user_id ORDER BY date, id)，补id防重复排序打乱 - 别用
LAG(date, 1)默认偏移量就足够，显式写1反而冗余 - 计算“是否连续”时，用
date - LAG(date) OVER (...) = INTERVAL '1 day'，别用=比较字符串 - PostgreSQL需注意
NULLS LAST（避免NULL排最前导致首行LAG拿不到值）
连续段识别：用LAG() + 累计标记做分组
只靠LAG()能看出“当前行是否连上前一行”，但要圈出完整连续段（比如用户A在2026-04-01~04-03连续登录），得把连续行打上同一标签——这时候需要累计计算。
关键不是“有没有断”，而是“断点在哪”。每次LAG()发现不连续，就触发一次分组编号递增。
实操建议：
- 先生成断点标识：
(date != LAG(date) OVER (PARTITION BY user_id ORDER BY date) + INTERVAL '1 day')::int - 再用
SUM(断点标识) OVER (PARTITION BY user_id ORDER BY date ROWS UNBOUNDED PRECEDING)生成连续段ID - 最后
GROUP BY user_id, 连续段ID算每段起止、长度 - MySQL 8.0+不支持
::int类型转换，改用IF(..., 1, 0)
性能陷阱：LAG()没走索引，比自连接还慢
LAG()本身不慢，慢在它强制触发全表排序。如果OVER (PARTITION BY user_id ORDER BY date)里date没索引，或复合索引没覆盖user_id, date，执行计划里就会出现Sort节点，大表直接卡住。
自连接若已有(user_id, date)联合索引，可能只扫几行就命中上一条；LAG()却得先把百万行按user_id+date排完再取。
实操建议：
- 建索引优先级：先
CREATE INDEX idx_user_date ON events(user_id, date)，别只建date单列索引 - EXPLAIN看执行计划，确认
LAG()所在查询走的是Index Scan而非Seq Scan或Sort - 如果业务只要最近7天的连续性分析，先
WHERE date >= CURRENT_DATE - INTERVAL '7 days'再开窗口，缩小数据集
为什么不能在WHERE里直接用LAG()
因为窗口函数在SQL逻辑执行顺序中晚于WHERE——WHERE跑的时候，LAG()根本还没算出来。你写WHERE LAG(date) = ...，数据库直接报错invalid reference to FROM-clause entry或类似提示。
这不是语法糖问题，是执行阶段硬限制。想过滤，必须套一层子查询或CTE。
实操建议：
- 正确写法：
SELECT * FROM (SELECT *, LAG(date) OVER (PARTITION BY user_id ORDER BY date) AS prev_date FROM login_log) t WHERE date - prev_date = INTERVAL '1 day'
- 别省事写成
HAVING——HAVING只对GROUP BY有效，这里没分组 - CTE可读性更好，但MySQL 8.0以下不支持，得用派生表
- 注意子查询别名
t后必须显式列出字段，否则*可能包含重复列名报错
连续段识别那步的累计标记，最容易被忽略的是排序字段的稳定性——哪怕date唯一，不同数据库对NULL的默认排序也不同，NULLS FIRST/LAST不声明，测试环境OK，上线就错。
