自连接找连续日期的合理前提是：login_date必须为date类型、已去重且无null，否则关联结果失真；其本身不识别连续，真正依赖日期差值计算与分组逻辑。
什么是自连接找连续日期的合理前提
自连接本身不保证“连续”，它只是把同一张表当两张表来关联。真正识别连续日期，靠的是日期差值计算和分组逻辑。如果原始数据里 user_id 和 login_date 有重复、缺失或时区混乱，自连接结果会直接失真。务必先确认：login_date 是 DATE 类型（不是 DATETIME），且已去重、无 NULL。
常见错误现象：用 DATE_ADD(t1.login_date, INTERVAL 1 DAY) = t2.login_date 关联后，发现连续3天的用户只被算作两段“连续2天”，这是因为该条件只能捕获相邻两天，无法直接泛化到 N 天。必须配合变量或窗口函数做序列标记。
用变量模拟 row_number 实现连续段分组（MySQL 5.7 兼容）
MySQL 5.7 不支持 ROW_NUMBER()，但可以用用户变量给每个用户按日期排序打序号，再用“日期 - 序号”作为连续性锚点——同一连续段内这个差值恒定。
实操建议：
- 先按
user_id、login_date排序，确保变量递增顺序可靠 - 变量初始化写在子查询里，避免会话级变量污染：
SELECT user_id, login_date, @rn := IF(@prev = user_id, @rn + 1, 1) AS rn, @prev := user_id FROM (SELECT user_id, login_date FROM logins ORDER BY user_id, login_date) t, (SELECT @rn := 0, @prev := NULL) init - 外层对
login_date - INTERVAL rn DAY分组，该值相同即属同一连续段
用窗口函数高效识别连续段（MySQL 8.0+ / PostgreSQL）ROW_NUMBER() 是更稳定的选择，尤其当数据量大或并发高时，变量容易出错。
关键逻辑：对每个 user_id 按 login_date 排序，生成序号；再用 login_date - INTERVAL ROW_NUMBER() DAY 得到连续段标识符。
示例（MySQL 8.0）：
WITH ranked AS (
SELECT user_id, login_date,
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY login_date) AS rn
FROM logins
),
grouped AS (
SELECT user_id,
DATE_SUB(login_date, INTERVAL rn DAY) AS grp
FROM ranked
)
SELECT user_id, MIN(login_date) AS start_date, MAX(login_date) AS end_date, COUNT(*) AS days
FROM grouped
GROUP BY user_id, grp
HAVING COUNT(*) >= 3;
注意：DATE_SUB(login_date, INTERVAL rn DAY) 在 PostgreSQL 中要写成 login_date - rn * INTERVAL '1 day'，语法略有差异。
为什么 WHERE 条件不能放在 ON 里？自连接性能陷阱
有人写 ON t1.user_id = t2.user_id AND DATEDIFF(t2.login_date, t1.login_date) = 1，再在 WHERE 里筛 t1.login_date 范围——这会导致 MySQL 无法有效使用索引，全表扫描风险极高。
正确做法：
- 把日期范围过滤放在最外层
WHERE，让优化器先剪枝 - 确保
(user_id, login_date)有联合索引，顺序不能颠倒 - 避免在
ON或WHERE中对login_date做函数运算，例如DATE(t1.login_date)会失效索引
连续段识别真正的复杂点不在 JOIN 本身，而在如何定义“连续”——是自然日连续？跳过周末？是否接受跨月？这些业务规则必须提前固化到日期预处理中，而不是指望自连接自动理解。
