<p>SELF JOIN识别连续记录的本质是通过t1.id = t2.id - 1关联相邻行，并用WHERE限定方向和业务条件（如t1.status = t2.status = 'active'）避免重复与遗漏；若无天然序号，需先用ROW_NUMBER()生成逻辑序号；MySQL 8.0+推荐用id - ROW_NUMBER()分组法高效提取连续区间。</p>
SELF JOIN怎么写才能识别“连续”
连续记录的本质是：当前行的某个字段值，等于前一行该字段值加1（或减1）。SELF JOIN 的核心思路是把同一张表当作两张表，用 t1.id = t2.id - 1 这类条件关联相邻行。但直接写 ON t1.id = t2.id - 1 很容易漏掉边界或重复匹配，必须配合 WHERE 筛选有效组合。
常见错误现象：JOIN 后返回大量空行、同一组连续记录被拆成多对、或跳过长度为2的连续段。
- 务必用
WHERE限定方向，比如只找t1.id < t2.id，避免 (1,2) 和 (2,1) 重复出现 - 如果连续依据是日期（如
log_date），别用= DATE_ADD(t2.log_date, INTERVAL -1 DAY)做 JOIN 条件——日期可能不全，应先用DATE_ADD计算期望值，再在WHERE中检查是否存在 - 连续判断必须基于有序字段；若原始表无主键/时间戳等天然序号，先用
ROW_NUMBER()生成逻辑序号再 JOIN
查出所有连续ID区间（起止+长度）
单纯找出相邻对只是第一步。真正实用的是合并成区间，比如 ID 5-7、12-15。这需要两层 SELF JOIN 或窗口函数辅助——但纯 SQL（尤其 MySQL 5.7）常用双 JOIN 模拟“起点”和“终点”。
典型做法：用第一个表 t_start 表示连续段起点（即它前面没有前驱），第二个表 t_end 表示终点（后面没有后继），再通过子查询或 JOIN 关联它们。
- 起点判定：
NOT EXISTS (SELECT 1 FROM logs l2 WHERE l2.id = t_start.id - 1) - 终点判定：
NOT EXISTS (SELECT 1 FROM logs l2 WHERE l2.id = t_end.id + 1) - 再用
JOIN把起点和终点连起来，要求t_start.id <= t_end.id且中间无断点（可通过NOT EXISTS检查区间内缺失）
性能提示：这类查询在大数据量下容易变慢，建议对用于连续判断的字段（如 id 或 created_at）建索引。
MySQL 8.0+ 用 ROW_NUMBER() 更稳
传统 SELF JOIN 在处理“连续相同状态”（比如连续三天 status='active'）时非常吃力，因为要同时比对字段值和序号。MySQL 8.0+ 的窗口函数让这事清晰得多：先按时间排序打序号，再用 id - ROW_NUMBER() 构造分组标识。
例如：
SELECT MIN(id) AS start_id, MAX(id) AS end_id, COUNT(*) AS length FROM ( SELECT id, id - ROW_NUMBER() OVER (ORDER BY id) AS grp FROM logs WHERE status = 'active' ) t GROUP BY grp;
关键点在于：grp 相同的行，说明它们的 id 是连续的。这个技巧不依赖主键是否密集，也不怕中间有删除——只要数据本身连续，grp 就一致。
- 如果连续依据是时间，把
ORDER BY id换成ORDER BY created_at，并确保时间字段无重复；有重复时加id作二级排序 -
ROW_NUMBER()必须带OVER，否则报错Window function is missing OVER clause - 注意：MySQL 5.7 不支持窗口函数，强行用会报错
FUNCTION xxx.ROW_NUMBER does not exist
WHERE 条件放 JOIN 内还是外？
这是最容易踩坑的地方。如果你在 SELF JOIN 的 ON 子句里写 AND t1.status = 'active'，实际效果是“只连接 status='active' 的前驱”，但可能漏掉起点本身不是 active 的情况。正确做法是把业务过滤条件统一放在 WHERE。
对比：
- ❌ 错误（过滤提前，丢失起点）：
ON t1.id = t2.id - 1 AND t1.status = 'active' - ✅ 正确（先连所有相邻对，再筛）：
ON t1.id = t2.id - 1 WHERE t1.status = 'active' AND t2.status = 'active'
特别是查“连续N天”的场景，必须保证每一对都满足条件，否则区间会断裂。少写一个 t2.status 判断，结果就不可靠。
连续性判断看似简单，但真实数据里总有空缺、重复、乱序。别迷信单次 JOIN 能搞定，先确认字段是否真有序，再决定用窗口函数还是嵌套子查询——后者可读性差，但兼容老版本；前者简洁，却绕不开版本限制。
