1. 项目概述：从业务需求到SQL挑战

在用户行为分析、活动运营和用户留存评估中，“连续登录天数”和“最大连续登录天数”是两个极其核心的指标。前者能告诉我们用户最近是否保持活跃，是触发“断签提醒”或“连续签到奖励”的直接依据；后者则刻画了用户历史上最忠诚、最稳定的活跃周期，对于用户分层和生命周期价值预测至关重要。作为一名数据分析师或后端开发，你很可能接过这样的需求：“统计一下最近7天连续登录的用户”、“找出本月连续登录满15天的用户发放奖励”，或者“分析一下我们核心用户的平均最大连续登录天数”。

面对这样的需求，如果数据量不大，用程序（比如Python或Java）逐条遍历用户日志，用变量记录状态进行计算，似乎是个直观的选择。但一旦登录日志表膨胀到百万、千万甚至亿级，这种方法的效率瓶颈就立刻显现，I/O和计算开销会变得难以承受。此时，在数据库层面，直接用SQL完成这类复杂序列计算，就成为了必须掌握的高阶技能。这不仅仅是写一句SELECT COUNT(*)那么简单，它考验的是你对SQL窗口函数、日期处理、分组聚合乃至递归查询的深刻理解和灵活运用。

今天，我们就来彻底拆解这个经典问题。我将以一个模拟的用户登录日志表为例，手把手带你从最基础的思路开始，逐步推导出高效、可靠的SQL解决方案。无论你用的是MySQL 8.0+、PostgreSQL、SQL Server还是其他支持窗口函数的现代数据库，核心思路都是相通的。我们会深入每个步骤背后的“为什么”，并分享我在实际工作中踩过的坑和总结的优化技巧。

2. 数据准备与问题定义

在开始编写SQL之前，清晰的定义和合理的数据模拟是成功的一半。我们先来搭建实验环境。

2.1 创建测试表与数据

假设我们有一张名为user_login的表，它记录了用户的每一次登录事件。一个精简且高效的设计通常包含以下字段：

CREATE TABLE user_login ( login_id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT '登录记录ID', user_id INT NOT NULL COMMENT '用户ID', login_date DATE NOT NULL COMMENT '登录日期（精确到天）', login_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP COMMENT '登录具体时间戳', INDEX idx_user_date (user_id, login_date) ) COMMENT '用户登录日志表';

字段设计解析：

• login_date (DATE)：这是核心字段。我们通常关心的是“天”维度的连续性，所以将日期单独存储为DATE类型，与具体时间戳分离，便于直接进行日期计算和去重。如果只有login_time (TIMESTAMP)，则需要频繁使用DATE(login_time)函数转换，影响性能且不利于索引优化。
• INDEX idx_user_date (user_id, login_date)：复合索引。几乎所有查询都会先按user_id分组，再按login_date排序或筛选，这个索引能极大加速查询过程。

接下来，我们插入一些模拟数据，注意要构造包含连续登录、中断登录、重复登录（同一天多次登录）等复杂情况：

INSERT INTO user_login (user_id, login_date) VALUES (1, '2023-10-01'), (1, '2023-10-02'), (1, '2023-10-03'), -- 用户1， 连续3天 (1, '2023-10-05'), -- 中断1天 (10-04没登录) (1, '2023-10-06'), (1, '2023-10-06'), -- 同一天重复登录 (1, '2023-10-07'), -- 用户1， 后续连续3天 (10-05, 06, 07) (2, '2023-10-01'), (2, '2023-10-02'), (2, '2023-10-04'), -- 中断1天 (10-03没登录) (2, '2023-10-05'), (2, '2023-10-08'), -- 中断2天 (2, '2023-10-09'), (3, '2023-10-10'); -- 用户3， 只有一次登录

2.2 明确计算目标

基于上表，我们需要为每个用户计算两个指标：

1. 当前连续登录天数：以数据中最后一天（‘2023-10-10’）为截止点，用户最近一次连续登录持续了多少天。例如，用户1最后登录是10-07，但10-08、10-09、10-10都没登录，所以他的“当前连续登录”在10-10这天看是0天。更常见的需求是“截至昨天的连续登录天数”，即看‘2023-10-09’。
2. 历史最大连续登录天数：用户在所有历史时间段内，最长的一次连续登录持续了多少天。例如，用户1有过3天（10-01至10-03）和3天（10-05至10-07）的连续登录，最大值为3。用户2的登录序列比较散，需要计算。

注意：在实际业务中，“连续登录”通常指自然日的连续，不考虑一天内的多次登录。因此，去重(DISTINCT login_date) 是第一步，也是最容易被忽略的一步。如果不去重，用户1在10-06日的两次登录会被错误地计算为两天。

3. 核心思路拆解：如何用SQL识别连续区间

识别连续日期序列，是解决本问题的核心。其关键思路在于：如果一组日期是连续的，那么为这组日期减去一个递增的序号，得到的差值（或基准日期）将是相同的。

这个思路可能有点绕，我们通过一个具体的计算过程来直观理解。假设用户1去重后的登录日期序列如下：

计算过程解析：

1. 首先，我们为每个用户按登录日期升序生成一个连续的行号（rn）。
2. 然后，我们将login_date（日期类型）减去一个由rn转换而来的天数间隔（rn - 1天）。在SQL中，login_date - INTERVAL (rn-1) DAY。
3. 观察结果：对于一段连续的日期，减去其行号偏移量后，它们会“对齐”到同一个起始日期。例如，10-01, 10-02, 10-03分别减去0, 1, 2天后，都变成了2023-09-30。而10-05, 10-06, 10-07减去3, 4, 5天后，都变成了2023-10-01。
4. 这个“对齐后的日期” (group_base_date) 就成为了标识一个连续区间的完美分组键。同一个group_base_date下的所有login_date，必然属于同一个连续登录区间。

这个方法的精妙之处在于，它将“连续性”的判断，转化为了一个确定性的等值分组问题，从而可以轻松地利用GROUP BY进行聚合计算，求出每个连续区间的天数、起始日期和结束日期。

4. 分步实现：计算最大连续登录天数

理解了核心思路后，我们将其转化为具体的SQL语句。这里我们使用通用性较好的窗口函数语法。

4.1 步骤一：数据预处理与去重

首先，我们需要获取每个用户唯一的登录日期列表，并按用户和日期排序。这是所有后续计算的基础。

WITH DistinctLogin AS ( SELECT user_id, login_date FROM user_login GROUP BY user_id, login_date -- 按用户和日期去重 ) SELECT * FROM DistinctLogin ORDER BY user_id, login_date;

这一步确保了同一天多次登录只计为一天，符合业务定义。

4.2 步骤二：生成行号与连续区间标识

接下来，我们使用窗口函数为去重后的数据生成行号，并计算那个关键的“分组基准日期”。

WITH DistinctLogin AS (...), -- 同上 RankedLogin AS ( SELECT user_id, login_date, -- 为每个用户的登录日期生成连续行号 ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY login_date) AS rn FROM DistinctLogin ), GroupedLogin AS ( SELECT user_id, login_date, rn, -- 核心技巧：日期减去行号偏移量，得到连续区间的分组标识 DATE_SUB(login_date, INTERVAL (rn - 1) DAY) AS group_base_date FROM RankedLogin ) SELECT * FROM GroupedLogin ORDER BY user_id, login_date;

执行这个查询，你会得到类似前面表格的结果，group_base_date列清晰地标识出了不同的连续区间。

4.3 步骤三：按连续区间分组并统计天数

现在，我们可以按user_id和group_base_date进行分组，统计每个连续区间的天数、开始日期和结束日期。

WITH DistinctLogin AS (...), RankedLogin AS (...), GroupedLogin AS (...), ContinuousGroups AS ( SELECT user_id, group_base_date, COUNT(*) AS continuous_days, -- 该连续区间的天数 MIN(login_date) AS start_date, -- 区间开始日 MAX(login_date) AS end_date -- 区间结束日 FROM GroupedLogin GROUP BY user_id, group_base_date ) SELECT * FROM ContinuousGroups ORDER BY user_id, start_date;

查询结果将展示每个用户历史上的每一个连续登录区间及其长度。

4.4 步骤四：找出每个用户的最大连续天数

最后一步就很简单了，从ContinuousGroups中，为每个user_id找出continuous_days的最大值。

WITH DistinctLogin AS (...), RankedLogin AS (...), GroupedLogin AS (...), ContinuousGroups AS (...) SELECT user_id, MAX(continuous_days) AS max_continuous_days FROM ContinuousGroups GROUP BY user_id ORDER BY user_id;

最终整合的完整SQL查询：

WITH DistinctLogin AS ( SELECT user_id, login_date FROM user_login GROUP BY user_id, login_date ), RankedLogin AS ( SELECT user_id, login_date, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY login_date) AS rn FROM DistinctLogin ), GroupedLogin AS ( SELECT user_id, login_date, DATE_SUB(login_date, INTERVAL (rn - 1) DAY) AS group_base_date FROM RankedLogin ), ContinuousGroups AS ( SELECT user_id, group_base_date, COUNT(*) AS continuous_days FROM GroupedLogin GROUP BY user_id, group_base_date ) SELECT user_id, MAX(continuous_days) AS max_continuous_login_days FROM ContinuousGroups GROUP BY user_id ORDER BY user_id;

运行上述查询，针对我们的测试数据，你会得到：

• 用户1：最大连续登录天数为3(区间 10-01至10-03 和 10-05至10-07)。
• 用户2：需要计算一下，日期序列为01, 02, 04, 05, 08, 09。连续区间为[01,02]（2天）、[04,05]（2天）、[08,09]（2天），所以最大值是2。
• 用户3：只有一个日期，单独构成一个连续区间，天数为1。

5. 扩展实现：计算当前连续登录天数

“当前连续登录天数”是一个动态指标，取决于你选择的“当前日期”（CURRENT_DATE）。它的计算逻辑是：找到每个用户包含“当前日期”的连续登录区间，并计算该区间的长度。如果用户最近没有登录，或者在“当前日期”不连续，则天数为0。

我们假设以‘2023-10-09’作为计算截止日期（即查看用户截至昨天的连续登录情况）。

5.1 方法一：基于现有连续区间查询

我们可以复用前面计算出的所有历史连续区间 (ContinuousGroupsCTE)，然后判断哪个区间包含了我们指定的“当前日期”。

-- 假设当前日期是 2023-10-09 SET @target_date = '2023-10-09'; WITH DistinctLogin AS (...), RankedLogin AS (...), GroupedLogin AS (...), ContinuousGroups AS ( SELECT user_id, group_base_date, MIN(login_date) AS start_date, MAX(login_date) AS end_date, COUNT(*) AS continuous_days FROM GroupedLogin GROUP BY user_id, group_base_date ) SELECT user_id, COALESCE( (SELECT continuous_days FROM ContinuousGroups cg2 WHERE cg2.user_id = cg1.user_id AND @target_date BETWEEN cg2.start_date AND cg2.end_date), 0 ) AS current_continuous_days FROM (SELECT DISTINCT user_id FROM user_login) cg1 ORDER BY user_id;

逻辑解析：对于每个用户，在ContinuousGroups的子查询中寻找其start_date和end_date包含目标日期@target_date的区间。如果找到，则返回该区间的天数；如果找不到（用户在该日期未登录或不在连续区间内），则使用COALESCE函数返回0。

5.2 方法二：动态计算最近连续区间

更高效、更常用的方法是，不计算全部历史区间，而是直接针对目标日期，动态地回溯计算连续天数。这利用了“连续日期差值相等”的逆推特性。

SET @target_date = '2023-10-09'; WITH DistinctLogin AS ( SELECT user_id, login_date FROM user_login WHERE login_date <= @target_date -- 关键：只取截止日期及之前的登录记录 GROUP BY user_id, login_date ), RankedLogin AS ( SELECT user_id, login_date, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY login_date DESC) AS rn_desc -- 按日期倒序排 FROM DistinctLogin ), BacktrackGroups AS ( SELECT user_id, login_date, DATE_SUB(login_date, INTERVAL (rn_desc - 1) DAY) AS group_base_date FROM RankedLogin ), CurrentContinuous AS ( SELECT user_id, -- 计算从target_date开始往前连续的日期数量 COUNT(*) AS current_continuous_days FROM BacktrackGroups -- 关键筛选：只保留那些“分组基准日期”等于 target_date 所在分组基准日期的记录 -- 这实际上是在找从target_date开始往前连续的日期块 WHERE group_base_date = ( SELECT DATE_SUB(@target_date, INTERVAL (rn_desc - 1) DAY) FROM BacktrackGroups bg2 WHERE bg2.user_id = BacktrackGroups.user_id AND bg2.login_date = @target_date LIMIT 1 ) GROUP BY user_id ) SELECT u.user_id, COALESCE(cc.current_continuous_days, 0) AS current_continuous_days FROM (SELECT DISTINCT user_id FROM user_login) u LEFT JOIN CurrentContinuous cc ON u.user_id = cc.user_id ORDER BY u.user_id;

这个方法逻辑更精巧，它从目标日期开始倒序排列登录记录。如果从目标日期往前是连续的，那么这些连续日期的login_date - (倒序行号-1)会得到一个相同的值。我们通过子查询找到目标日期所在的这个“分组基准日期”，然后统计所有属于这个分组的日期数量，即为连续天数。

实操心得：方法二在计算“当前连续天数”时通常性能更好，尤其是当用户历史登录记录很长时，因为它不需要计算用户所有的历史连续区间，只关心最近的目标日期附近的情况。但是逻辑上更复杂一些。在实际生产中，如果只需要“当前连续天数”，推荐使用方法二。如果需要同时计算“最大”和“当前”，那么使用方法一的变体（计算所有区间）可能代码复用性更高。

6. 性能优化与常见问题排查

当user_login表数据量巨大时，上述查询可能会遇到性能瓶颈。以下是一些关键的优化思路和常见问题。

6.1 索引优化是重中之重

没有合适的索引，窗口函数ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY login_date)会导致全表扫描和昂贵的排序操作。

• 必须创建的索引：(user_id, login_date)复合索引。它完美匹配了窗口函数中的PARTITION BY和ORDER BY子句，能让数据库高效地按用户分组并按日期排序，是性能提升的关键。
• 考虑包含索引：如果login_date是从login_time派生出来的（例如DATE(login_time)），那么在这个派生列上创建索引是无效的。此时应直接存储login_date列，或者考虑创建函数索引（如果数据库支持，如PostgreSQL的((login_time::DATE))）或生成列（Generated Column）。

6.2 减少中间结果集大小

在CTE的每一步，尤其是DistinctLogin阶段，应尽早应用过滤条件。

• 按时间范围筛选：业务查询往往只关心最近一段时间（如最近90天、一年）的数据。在DistinctLoginCTE的初始查询中，务必加上WHERE login_date >= ‘某个起始日期’。这能极大地减少需要处理的数据量。
• 避免过早排序：在CTE链中，只有最后一步需要ORDER BY输出结果。确保中间的CTE步骤没有不必要的ORDER BY，除非数据库优化器能将其消除。

6.3 处理大数据量的分页与抽样

对于亿级数据，直接计算全量用户的最大连续登录天数可能非常慢。可以考虑：

• 分批次计算：按user_id的范围分批计算，例如WHERE user_id BETWEEN 1 AND 100000。
• 抽样分析：对于非实时监控场景，可以随机抽样一部分用户（如1%）进行计算，以评估整体用户行为分布。
• 物化视图/定期任务：对于需要频繁查询的指标（如每日更新当前连续登录天数），最好的办法是使用定时任务（如每日凌晨）预先计算好结果，存入一张汇总表user_login_stats (user_id, max_continuous_days, current_continuous_days, last_login_date)。查询时直接查汇总表，性能是O(1)的。

6.4 常见问题与排查技巧

1. 结果天数比预期多：首先检查是否进行了日期去重。这是新手最容易犯的错误。同一天多次登录必须用GROUP BY user_id, login_date或DISTINCT user_id, login_date处理掉。
2. 查询速度极慢：
   • 检查执行计划：使用EXPLAIN或EXPLAIN ANALYZE命令查看SQL执行计划。重点关注是否有全表扫描（FULL TABLE SCAN）或全索引扫描，以及排序（FILESORT）操作是否发生在磁盘上。
   • 确认索引生效：确保(user_id, login_date)索引被使用。在执行计划中，你应该看到Using index或Index Scan。
   • 调整数据库参数：对于超大数据集，可能需要临时增加排序缓冲区（如MySQL的sort_buffer_size）的大小。
3. 跨年或闰月计算错误：我们使用的DATE_SUB(login_date, INTERVAL (rn-1) DAY)方法是基于日期间隔的，数据库的日期函数会正确处理跨月、跨年甚至闰年的情况，所以通常不会有问题。但要确保你的login_date字段是标准的DATE类型。
4. “当前连续”计算为0，但用户明明最近有登录：检查你的“当前日期”（@target_date）参数是否正确。通常我们计算的是“截至昨天的连续登录”，所以@target_date应该是CURRENT_DATE - INTERVAL 1 DAY。如果你传入的是CURRENT_DATE，而用户今天还没登录，结果自然是0。

7. 不同数据库的语法差异与适配

核心算法是通用的，但不同数据库的日期计算和窗口函数支持略有差异。

• MySQL (8.0+): 本文示例主要使用MySQL语法。DATE_SUB(date, INTERVAL expr unit)是标准的日期减法。
• PostgreSQL: 日期减法更灵活，可以直接用login_date - (rn-1) * INTERVAL '1 day’，或者login_date - (rn-1) * ‘1 day’::interval。窗口函数语法相同。
• SQL Server: 使用DATEADD(DAY, -(rn-1), login_date)。窗口函数ROW_NUMBER()语法相同。
• SQLite: 早期版本不支持窗口函数，实现起来非常麻烦，需要用到自连接或递归CTE（如果版本支持）。对于复杂分析，建议将数据导出到其他数据库处理。
• 大数据平台 (Hive/SparkSQL): 语法与标准SQL类似，但需要注意性能。ROW_NUMBER()在大数据场景下是重操作，合理设置分区数(PARTITION BY)至关重要，应避免数据倾斜。

一个PostgreSQL的适配示例：

WITH DistinctLogin AS (...), RankedLogin AS ( SELECT user_id, login_date, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY login_date) AS rn FROM DistinctLogin ), GroupedLogin AS ( SELECT user_id, login_date, login_date - (rn - 1) * INTERVAL '1 day' AS group_base_date -- PostgreSQL日期减法 FROM RankedLogin ) ... -- 后续GROUP BY部分相同

掌握用SQL计算连续登录天数，不仅仅是解决了一个具体的业务问题，更是深入理解了序列分析和间隙与岛屿问题这一类SQL高级模式的钥匙。你可以用同样的思路去解决“连续购买天数”、“连续打卡天数”、“连续上涨的股票交易日”等众多相似问题。关键在于将“连续性”这一状态判断，转化为可分组聚合的确定性标签，这正是SQL从单纯的数据检索走向复杂数据分析的迷人之处。在实际工作中，结合索引优化和预计算策略，你就能在海量数据中游刃有余地驾驭这类计算。