用LAG()检测断层最稳：当前id与LAG(id)差值不为1即缺号；补缺需生成完整范围再左连接，避免用ROW_NUMBER()伪替代；注意索引、区间分段生成及空表NULL处理。
直接用嵌套查询识别序列号断档，大概率会慢得离谱，还容易漏掉边界情况。真正能跑得动的方案，取决于你用的数据库版本和数据特征。
为什么相关子查询(SELECT MAX(id) FROM t WHERE id
这种写法看着直观，但每查一行就触发一次全表扫描——10万行数据，就得扫10万次。实际执行时，EXPLAIN里会看到大量DERIVED表，内存撑不住就溢出到磁盘临时表。
- MySQL 5.7 默认不优化这类相关子查询，哪怕
id有索引也用不上 - 子查询返回
NULL时，curr.id - NULL结果为NULL，WHERE条件自动失效，断点直接消失 - 如果序列号是字符串（如
'SN-00123'），MAX()按字典序比，'SN-002'会大于'SN-00123'，结果错乱
MySQL 8.0+ 用 LAG() 代替嵌套查询
窗口函数才是正解，单次扫描就能拿到“上一行”，性能差一个数量级。关键不是语法多炫，而是必须确保排序稳定、索引有效。
-
ORDER BY id字段必须有索引，否则LAG()输出不可靠 - 别写
SELECT id, LAG(id) OVER (ORDER BY id)然后在应用层算差值——把计算压进SQL：WHERE id - LAG(id) OVER (ORDER BY id) > 1 - 如果原始
id含前导零或字母，先清洗再算：CAST(SUBSTR(id, 4) AS SIGNED)提取数字部分
SELECT id, prev_id FROM ( SELECT id, LAG(id) OVER (ORDER BY id) AS prev_id FROM serials ) t WHERE id - prev_id > 1;
MySQL 5.7 或 SQLite 怎么办
窗口函数不能用，但也不该退回相关子查询。自连接或变量模拟更可行，前提是数据顺序可控、无并发写入。
- 自连接方式：
SELECT s1.id FROM serials s1 LEFT JOIN serials s2 ON s1.id = s2.id + 1 WHERE s2.id IS NULL AND s1.id > (SELECT MIN(id) FROM serials)，能走id索引 - MySQL 5.7 用户变量方案：
SELECT id FROM (SELECT id, @prev AS prev_id, @prev := id FROM serials ORDER BY id) t WHERE id - prev_id > 1，但必须加ORDER BY且禁止被优化器重排 - SQLite 若没显式主键，可临时借
ROWID辅助，但仅限物理连续场景；逻辑序列仍需清洗后转数值再处理
业务规则比语法更容易让人栽跟头
断档检测真正卡住人的，从来不是怎么写SQL，而是业务定义模糊、数据格式混乱、规模超出预期。
- “断档”指什么？是跳号（1,2,4,5）、缺失（1,2,5,6）、还是最大连续段起点？不同定义对应完全不同的SQL逻辑
- 字符串型序列如
'SN-2023-001'，光截取数字不够，还得考虑年份是否参与排序 - 千万级数据下，
LAG()再快，没给id建索引，排序阶段照样磁盘溢出
