连续登录天数的“分组”本质是识别时间断点并构造恒定组锚：对每个用户按日期排序后，用login_date减去ROW_NUMBER()生成唯一group_id，同一连续段内该值恒定，断点处值突变，从而实现精准分组。
什么是连续登录天数的“分组”本质
连续登录不是按日期排序就能直接相减，关键在于识别“断点”——比如用户在 2024-01-01、01-02、01-04 登录，中间缺了 01-03，那 01-01 和 01-02 就自成一组连续段，01-04 是另一组起点。
核心思路是：对每个用户的登录日期排序后，用 ROW_NUMBER() 生成序号，再用日期本身减去这个序号。同一连续段内，date - ROW_NUMBER() 的结果恒定（称为“组锚”），不同段则值不同。
实操时注意：
- 必须先按 user_id 分组、再按 login_date 排序，否则 ROW_NUMBER() 乱序
- 日期类型需统一为 DATE，避免 DATETIME 带时分秒干扰减法结果
- PostgreSQL/MySQL 8.0+/SQL Server 支持窗口函数；MySQL 5.7 需用变量模拟，逻辑更脆
用 ROW_NUMBER() 构造连续段标识（group_id）
这是最通用、可读性最强的做法，适用于绝大多数现代 SQL 引擎：
SELECT
user_id,
MIN(login_date) AS start_date,
MAX(login_date) AS end_date,
COUNT(*) AS days_cnt
FROM (
SELECT
user_id,
login_date,
DATE_SUB(login_date, INTERVAL ROW_NUMBER() OVER (
PARTITION BY user_id ORDER BY login_date
) DAY) AS group_id
FROM user_login_log
) t
GROUP BY user_id, group_id
ORDER BY user_id, start_date;
要点说明：
- DATE_SUB(... INTERVAL ... DAY) 是 MySQL 写法；PostgreSQL 用 login_date - (ROW_NUMBER() OVER (...)::INT)
- PARTITION BY user_id 确保每个用户独立编号，不跨人混序
- 如果表中存在同日多次登录，需先 DISTINCT ON (user_id, login_date) 或 GROUP BY user_id, login_date 去重，否则 ROW_NUMBER() 会把同一天算作多个序号，导致 group_id 错位
统计最长连续登录天数或满足条件的用户
有了上一步的分组结果，后续聚合就很简单：
查每个用户的最长连续天数：
- 外层对 user_id 再 GROUP BY，用 MAX(days_cnt)
- 若还需返回起止日期，得用窗口函数 ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY days_cnt DESC) 取 Top 1
筛选连续登录 ≥ 7 天的用户：
- 在最终 GROUP BY 后加 HAVING COUNT(*) >= 7
- 注意不是 HAVING MAX(days_cnt) >= 7 —— 因为每行已是单个连续段，COUNT(*) 就是该段天数
常见错误：
- 直接对原始表用 LAG(login_date) 判断前一天是否存在，漏掉多日连续场景（只能抓相邻两日）
- 忘记 PARTITION BY user_id，导致所有用户被当成一个序列处理
- 用 login_date - ROW_NUMBER() 但没转成日期类型（如字符串拼接），计算结果不可比
MySQL 5.7 或旧版 SQLite 怎么办
这些环境不支持窗口函数，得靠自连接或变量：
变量法（MySQL 5.7）示例：
SET @row_number := 0; SET @prev_user := ''; SET @prev_date := NULL; <p>SELECT user_id, MIN(login_date), MAX(login_date), COUNT(*) FROM ( SELECT user_id, login_date, @row_number := CASE WHEN @prev_user = user_id AND DATEDIFF(login_date, @prev_date) = 1 THEN @row_number ELSE @row_number + 1 END AS group_id, @prev_user := user_id, @prev_date := login_date FROM user_login_log ORDER BY user_id, login_date ) t GROUP BY user_id, group_id;</p>
风险提示：
- 变量执行顺序依赖 ORDER BY，若优化器改写执行计划可能出错
- 不支持并行查询，大数据量下性能差且不可靠
- SQLite 没有用户变量，只能用自连接，N² 复杂度，万级数据就明显卡顿
连续登录分析真正的难点不在语法，而在于业务定义是否清晰：是否排除节假日？凌晨跨日算不算？同一用户多设备登录是否合并？这些都会直接影响 GROUP BY 前的数据清洗逻辑。
