LAG()最适合识别连续登录断点，因其直接获取同用户前一行日期计算差值；需按user_id分组、login_date升序排序，并用gap_days>1标记断点，再通过累计断点生成组ID实现连续段统计。
用 LAG() 和日期差识别断点
连续登录的核心是“上一次登录和本次登录是否隔了1天”。直接算连续段，不如先标记出所有“断点”——也就是当前登录日期减去上一次登录日期 > 1 的那些行。LAG() 是最轻量、最直观的选择，它能拿到按用户+时间排序后的前一行数据，无需自连接或子查询。
关键点：必须对每个 user_id 单独排序，且按 login_date 升序；LAG(login_date) 返回的是日期类型，相减结果才是天数（PostgreSQL/MySQL 8.0+/SQL Server 支持直接减，SQLite 需用 julianday()）。
常见错误：
– 忘记 PARTITION BY user_id，导致跨用户比较
– 用 LEAD() 反向推导，逻辑绕且易漏首尾
– 在 WHERE 中直接对窗口函数结果过滤（语法不支持，得套一层子查询或 CTE）
示例（PostgreSQL）：
SELECT user_id, login_date,
login_date - LAG(login_date) OVER (PARTITION BY user_id ORDER BY login_date) AS gap_days
FROM user_logins;用 ROW_NUMBER() 构造连续组 ID
识别出断点后，真正的连续段就藏在“累计断点次数”里。给每条记录打一个“组号”：只要前面出现一次 gap_days > 1，组号就 +1。最稳的方式是用 ROW_NUMBER() 分别按用户全局排序、再按用户+连续逻辑排序，两者相减得到稳定组 ID。
为什么不用 COUNT() OVER ... RANGE？因为窗口聚合无法动态响应断点位置；而两次 ROW_NUMBER() 相减，本质是把物理顺序和逻辑连续顺序的偏移量化成整数，天然抗重复日期、抗乱序（只要排序字段唯一）。
注意：
– 两个 ROW_NUMBER() 的 ORDER BY 子句必须一致（都用 login_date），否则组 ID 失效
– 如果同一天有多次登录，需先去重（DISTINCT ON (user_id, login_date) 或 GROUP BY）
示例（续接上一步）：
WITH ranked AS (
SELECT user_id, login_date,
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY login_date) AS rn_all,
ROW_NUMBER() OVER (
PARTITION BY user_id
ORDER BY login_date - INTERVAL '1 day' *
COUNT(*) FILTER (WHERE gap_days > 1)
OVER (PARTITION BY user_id ORDER BY login_date)
) AS rn_cont
FROM (/* 上一步的 gap 查询 */) t
)用 MIN()/MAX() 窗口聚合算每段长度
有了组 ID（比如叫 grp_id），连续天数就是该组内最大日期减最小日期 + 1。但更常用的是直接统计该组内记录数——用 COUNT(*) OVER (PARTITION BY user_id, grp_id)，它天然处理单日多次登录（计为1天还是多天，取决于你是否已去重）。
性能提示：
– 不要用 GROUP BY user_id, grp_id 再关联原表，窗口聚合一次到位
– 如果只关心“是否连续7天以上”，可在外层加 HAVING COUNT(*) >= 7，避免计算所有段
容易踩的坑：
– 把 grp_id 当成绝对序号（它只是相对分组标识，不同用户间不可比）
– 对未定义 grp_id 的首行（LAG() 为 NULL）不做处理，导致该行被排除或归入错误组（应在构造 grp_id 时用 COUNT() FILTER 或 SUM(CASE WHEN gap_days > 1 THEN 1 ELSE 0 END) OVER ...）
MySQL 5.7 或旧版 PostgreSQL 怎么办
这些版本不支持 LAG() 或 FILTER，就得用变量模拟窗口逻辑。核心是用 @prev_user 和 @prev_date 在排序后逐行比对，手动维护“当前连续天数”和“当前段起始日”。
风险点极高：
– MySQL 变量执行顺序无官方保证，ORDER BY 必须出现在变量赋值语句的同一 SELECT 中，且不能有优化干扰（如隐式排序、索引跳过）
– 没有 PARTITION BY，必须靠 IF(@prev_user != user_id, ...) 重置状态
– 一旦中间加了 LIMIT 或子查询，变量行为可能完全错乱
务实建议：如果数据量不大，导出后用 Python/Pandas 处理反而更可靠；如果必须在库内跑，优先升级到 MySQL 8.0+ 或迁移到支持标准窗口函数的引擎。
