left join能暴露缺失值，因以完整序列为主表，右表匹配不到时字段为null，从而精准定位跳号；inner join仅关联现存记录，天然忽略空缺。
为什么用 LEFT JOIN 比 INNER JOIN 更容易发现跳号
跳号的本质是「本该存在但实际缺失」，比如日志序号应为 1,2,3,4,5，却只查到 1,2,4,5 —— 缺失的 3 就是目标。用 INNER JOIN 只能关联已存在的记录，天然漏掉空缺；而 LEFT JOIN 以完整序列为主表，右表匹配不到时字段为 NULL，一眼就能揪出断点。
常见错误是先 SELECT * FROM logs 再人工比对，数据量一过万就不可靠。正确做法是构造连续序号序列再左连日志表。
- MySQL 8.0+ 可用
WITH RECURSIVE生成序列，注意递归深度默认 1000，跳号跨度过大需调cte_max_recursion_depth - PostgreSQL 用
GENERATE_SERIES()最稳，但注意起始/结束值必须落在真实日志id范围内，否则会误报边界外的“跳号” - SQLite 不支持递归 CTE 或生成函数，得靠自连接或外部脚本预生成序列表，否则无法纯 SQL 实现
如何用 ROW_NUMBER() 定位「逻辑连续但物理不连续」的跳号
有些系统日志用时间戳排序，但同一秒内多条记录导致 ORDER BY created_at 无法唯一确定顺序，此时直接查 id 差值会误判。真正要检查的是「按业务逻辑排序后的序号是否连续」，而不是原始主键。
例如：按 created_at, trace_id 排序后，用 ROW_NUMBER() OVER (ORDER BY created_at, trace_id) 生成逻辑序号 rn，再与 id 或另一字段对比差值。
- 差值恒定（如
id - rn = 100）说明无跳号；若某行id - rn > 100 + 1，则中间至少缺一条 - 务必在
OVER子句里明确PARTITION BY（如按service_name分组），否则跨服务混排会导致误报 -
ROW_NUMBER()在大数据集上性能敏感，建议在排序字段上有联合索引，比如(created_at, trace_id)
排查时如何避免把「正常间隙」当成异常跳号
日志表中 id 不连续未必是问题：软删除、事务回滚、批量插入跳号、分库分表 ID 生成策略（如 Snowflake）都会造成物理间隙。关键要区分「业务要求的连续性」和「存储层的连续性」。
典型场景：支付流水号必须严格递增无跳号，而用户操作日志的 id 只要唯一即可。判断依据不是技术现象，而是业务契约。
- 先确认该字段是否被下游系统（如对账平台）当作连续序列消费，查文档或问对接方
- 检查跳号前后记录的
created_at时间差，若超过业务容忍阈值（如 5 秒无新日志），可能真是系统卡死而非 ID 间隙 - 用
SELECT MIN(id), MAX(id), COUNT(*) FROM logs快速估算缺口比例，(MAX - MIN + 1) - COUNT> 0.1% 才值得深挖
MySQL 中用变量模拟序列时容易踩的坑
MySQL 5.7 或更低版本不支持窗口函数和递归 CTE，有人用用户变量 @row := @row + 1 构造序号，但结果不稳定 —— MySQL 不保证变量赋值顺序，尤其在 ORDER BY 和变量同时出现时。
真实案例：同一语句执行两次，一次返回跳号位置正确，另一次全乱。根本原因是优化器可能重排执行计划，导致变量未按预期顺序更新。
- 必须写成子查询嵌套，且外层
SELECT不含ORDER BY，内层强制ORDER BY并加LIMIT防止优化器干预 - 变量初始化必须在同一语句中完成，分开的
SET @row = 0在某些客户端（如 PHP PDO）下会失效 - 更稳妥的做法是升级到 MySQL 8.0+ 直接用
ROW_NUMBER()，变量方案仅作临时救急
跳号排查真正的难点不在 SQL 写法，而在界定「什么是值得报警的跳号」—— 日志表结构、ID 生成机制、业务 SLA、上下游依赖，缺一不可。写完查询后，记得拿结果反向验证：这个「跳号」是否真会导致某笔订单对不上账？
