核心思路是用行号差法：子查询生成按用户分组、日期排序的行号rn，再用date_sub(login_date, interval rn day)计算连续段分组键，相同差值即为连续登录；须去重、过滤null、建联合索引。
子查询怎么配合日期差计算连续登录天数
核心思路是：把每个用户每天的登录记录当作一个点，用当前日期减去按用户分组、按日期排序后的行号，相同差值就代表连续登录。子查询在这里负责生成带行号的中间结果。
常见错误是直接对 login_date 做 LAG() 或 DATE_SUB() 比较，但没处理用户分组，导致跨用户误判连续；或者用自连接暴力匹配 7 天，性能爆炸且难维护。
- 必须用
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY login_date)生成序号，不能只用ROW_NUMBER() OVER (ORDER BY login_date) - 日期字段必须是
DATE类型（不是DATETIME），否则DATE_SUB(login_date, INTERVAL rn DAY)可能因时分秒偏差导致差值不等 - MySQL 8.0+、PostgreSQL、SQL Server 支持窗口函数；MySQL 5.7 只能用变量模拟行号，逻辑更脆弱
为什么用 GROUP BY user_id, DATE_SUB(login_date, INTERVAL rn DAY)
这个表达式是关键——它把“连续登录序列”映射成唯一分组键。比如用户 A 在 2024-01-01、02、03 登录，rn 是 1/2/3，则 DATE_SUB(...) 结果全是 2024-01-00（即 2023-12-31），三行归为一组。
如果漏掉 user_id，不同用户的登录日会混进同一组；如果用 DATE_ADD 替代 DATE_SUB，逻辑不变但可读性下降。
- PostgreSQL 需写成
login_date - INTERVAL '1 day' * rn - SQL Server 要用
DATEADD(day, -rn, login_date) - 注意：所有数据库中该差值是日期类型，不能和字符串或数字直接比较
子查询嵌套层级怎么控制才不超内存或超时
三层嵌套很常见：最内层去重 + 排序，中间层算差值，外层分组计数。但每多一层，临时结果集可能翻倍。
容易被忽略的是：没在原始表上对 (user_id, login_date) 建联合索引，导致排序阶段全表扫描。尤其当单日登录量大时，ROW_NUMBER() 性能断崖下跌。
- 先执行
SELECT DISTINCT user_id, DATE(login_time) AS login_date FROM log_table去重（避免同天多次登录干扰连续判断） - 子查询别名必须显式声明，如
AS ranked，否则 MySQL 8.0 报错Every derived table must have its own alias - 在 WHERE 中过滤出
cnt >= 7，不要在 HAVING 里留太多中间组
遇到 NULL 或重复日期怎么兜底
真实日志常有脏数据：login_date 为 NULL、同用户同天多条记录、时间戳精度不一致。这些会导致行号错位或差值计算异常。
子查询里不处理，外层 GROUP 就会少统计或报错。比如 MySQL 对 NULL 做 DATE_SUB(NULL, INTERVAL 1 DAY) 返回 NULL，整组丢失。
- 内层子查询必须加
WHERE login_date IS NOT NULL - 用
GROUP BY user_id, DATE(login_time)替代原始字段，强制归一化 - 若需兼容时区，统一转为 UTC 再截日期，例如
DATE(CONVERT_TZ(login_time, '+08:00', '+00:00'))
连续登录判断真正难的不是语法，是日期归一化和空值防御——这两点漏掉一个，结果就不可信。
