SQL分组查询连续登录超3天用户

处理连续登录问题，核心思路其实就一句话：用`ROW_NUMBER()`给登录日期编号，再拿日期减去这个编号。你会发现，同一个连续段里，减出来的结果完全一致。比如，如果某用户在2024-01-01、01-02、01-03都有登录记录，编号分别是1、2、3，那么用日期分别减去对应编号，都会得到2023-12-31——这个共同的结果，就是连续段的“锚点”，也是我们分组判断的依据。 这里有三个细节值得留意： * `ROW_NUMBER()`必须按`user_id`分组、并按`login_date`排序，否则编号顺序会全乱套。 * 日期字段的格式要统一。如果`login_date`是`DATETIME`类型、带有时分秒，得先通过`CAST(login_date AS DATE)`把它转成纯日期，不然计算会出问题。 * MySQL 8.0+、PostgreSQL、SQL Server这些主流数据库都原生支持`ROW_NUMBER()`；但如果你还在用MySQL 5.7或更早版本，就只得用变量来模拟了——不仅容易出错，还影响性能，建议尽快升级或者换方案。 得到锚点列（通常命名为`grp`或`group_id`），接下来的操作就很直观了：对`user_id`和`grp`做联合分组，然后用`COUNT(*)`统计每组的天数。 一个典型的SQL写法如下：

SELECT user_id
FROM (
  SELECT 
    user_id,
    login_date,
    DATE_SUB(login_date, INTERVAL ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY login_date) DAY) AS grp
  FROM login_log
) t
GROUP BY user_id, grp
HA VING COUNT(*) > 3;

注意一下`HA VING`条件：`COUNT(*) > 3`表示“超过3天”，也就是至少连续登录4天；如果需要“大于等于3天”，那么把`> 3`改成`>= 3`就行。 ### 重复登录与跨年边界的处理方式 用户同一天多次登录是一个常见陷阱——如果不处理，`COUNT(*)`的结果会偏大，导致统计失真。解决办法是：在子查询里先用`DISTINCT user_id, login_date`去重，或者用`GROUP BY user_id, login_date`预聚合一下。 至于跨年，其实不是什么大问题。`DATE_SUB`函数在MySQL里能正确处理，比如`2023-12-31 - INTERVAL 1 DAY = 2023-12-30`，不会有边界问题。但如果你用的是Oracle或PostgreSQL，日期运算的语法会有所不同：PostgreSQL需要写成`login_date - ROW_NUMBER() OVER (...)::INT`，Oracle则用`login_date - ROW_NUMBER() OVER (...)`。 ### 性能优化的关键：一个恰当的联合索引 如果没有合适的索引，`PARTITION BY user_id ORDER BY login_date`这类操作在百万级数据上几乎必然导致全表扫描，速度会非常慢。 解决方案很明确：建立一个覆盖`user_id`和`login_date`的联合索引。

CREATE INDEX idx_user_login ON login_log (user_id, login_date);

这个索引能同时支撑分组、排序和去重，比两个单列索引的组合有效得多。如果你的表已经有主键包含了这两列，请确认一下列的顺序是否一致——`user_id`必须在前。 连续登录分析本身不复杂，真正的难点往往在数据质量上。空值、时区混杂、日志漏采，任何一个问题都可能让锚点计算失准。上线之前，一定记得用真实的样本数据把中间结果跑一遍验证一下。