DENSE_RANK()不能直接算连续活跃，因为它只按值排序赋号，不判断时间是否连续；需用DATE_SUB(login_date, INTERVAL ROW_NUMBER() OVER (...) DAY)构造恒定批次ID，再分组计数或套DENSE_RANK()得批次号。
为什么DENSE_RANK()不能直接算连续活跃？
DENSE_RANK() 是按排序值分组打序号，相同值得相同序号、不跳号——但它只看“当前行的值”，完全不感知时间是否连续。比如用户在 2023-01-01、01-03、01-04 登录，DENSE_RANK() 按日期排序只会给出 1、2、3，无法识别中间缺了 01-02 这个断点。
真正要识别“连续”必须引入日期差逻辑，核心思路是：把「连续日期」映射到同一个基准日（比如每段连续区间的首日），再按该基准日分组计数。
用 DATE_SUB + GROUP BY 构造连续批次标识
标准解法是先算出行内日期与“按顺序排列的序号”之间的差值：DATE_SUB(login_date, INTERVAL ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY login_date) DAY)。这个差值在连续日期下恒定，可作为批次 ID。
实操建议：
- 务必
PARTITION BY user_id，否则不同用户日期会互相干扰 - ORDER BY 必须是严格升序日期，若存在同天多次登录，需先去重或加次级排序（如
ORDER BY login_date, login_time） - MySQL 8.0+ 支持窗口函数；低版本需用变量模拟
ROW_NUMBER()，但并发下不稳定 - PostgreSQL 可直接用
ROW_NUMBER()，但注意DATE_SUB要换成login_date - (ROW_NUMBER() OVER (...) - 1) * INTERVAL '1 day'
示例片段（MySQL）：
SELECT
user_id,
login_date,
DATE_SUB(login_date, INTERVAL rn - 1 DAY) AS batch_start,
COUNT(*) OVER (PARTITION BY user_id, DATE_SUB(login_date, INTERVAL rn - 1 DAY)) AS days_in_batch
FROM (
SELECT
user_id,
login_date,
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY login_date) AS rn
FROM user_login
) t;如何给每个连续批次分配递增的批次号（类似 DENSE_RANK 效果）？
构造出 batch_start 后，再对它做一次 DENSE_RANK() OVER (PARTITION BY user_id ORDER BY batch_start)，就能得到从 1 开始、不跳号的批次编号。
关键点：
- 必须
PARTITION BY user_id，否则张三的第 2 批和李四的第 2 批会被当成同一批 - ORDER BY 用
batch_start（而非原始日期），确保最早连续段排第一 - 如果某用户有多个相同
batch_start的记录（比如同一天多登），COUNT(*)会重复计数，需提前DISTINCT或用MIN(login_date)归一化
完整批次号字段写法：
DENSE_RANK() OVER (PARTITION BY user_id ORDER BY DATE_SUB(login_date, INTERVAL rn - 1 DAY)) AS batch_no
容易被忽略的边界情况
连续性判断对数据质量极度敏感：
- 日期字段类型必须是
DATE或能隐式转为日期的类型，VARCHAR存 '20230101' 会导致DATE_SUB失效 - 时区未统一时，跨 midnight 的日志可能被切到不同天，建议入库前标准化为 UTC 或业务本地日期
- 用户注销后重登、测试账号刷日志等异常行为，会产生极短批次（如仅 1 天），是否过滤需结合业务定义
- 若用
LAG()/LEAD()做差值判断，遇到空值或 NULL 日期会中断连续链，而基于ROW_NUMBER()的差值法更鲁棒
最常卡住的地方不是函数怎么写，而是没意识到：连续活跃的本质是「日期集合的连通分量」，必须靠数学变换暴露结构，而不是靠排名函数本身。
