lag()能精准定位每个断点：当前id与lag(id)差值>1即存在缺失，missing_start=prev_id+1，missing_end=curr_id−1；而min()/max()仅给出范围，无法识别具体缺哪些号。
直接用 LAG() 或 LEAD() 配合 WHERE 筛缺失更可靠，GROUP BY + MIN()/MAX() 只能查范围缺口，无法定位具体断点。
为什么不能只靠 MIN() 和 MAX() 找缺失序列号
这两个函数只能告诉你序列整体从几到几，比如 MIN(id) 是 1、MAX(id) 是 100，但完全不知道中间缺的是 5、23 还是 99 —— 它们不暴露空洞位置。
- 适用场景：仅需确认“是否连续”或估算缺口密度（如
COUNT(*)对比MAX()-MIN()+1） - 典型误用：写成
SELECT MIN(id)+1 FROM t WHERE id NOT IN (SELECT id+1 FROM t)，逻辑错且性能差 - 性能影响：全表扫描 + 子查询嵌套，在百万行表上可能超时
用 LAG() 定位每个断裂点（推荐 PostgreSQL / SQL Server / Oracle）
核心思路是把当前值和上一行的值做差，差不等于 1 就说明中间有跳号。
SELECT prev_id + 1 AS missing_start,
curr_id - 1 AS missing_end
FROM (
SELECT id,
LAG(id) OVER (ORDER BY id) AS prev_id
FROM serial_numbers
) t
WHERE id - prev_id > 1;
-
LAG(id)必须配ORDER BY id，否则顺序无意义 - 结果中
missing_start和missing_end相等表示单个缺失值（如缺 47），不等表示连续缺多个（如缺 102–105） - 注意：首行的
prev_id为NULL，id - NULL结果也是NULL，不会触发> 1条件，天然跳过
MySQL 8.0+ 同样可用 LAG()，但低版本得用自连接模拟
MySQL 5.7 或更早版本不支持窗口函数，只能用关联查询“手动找上一个”：
SELECT a.id + 1 AS missing_start,
b.id - 1 AS missing_end
FROM serial_numbers a
JOIN serial_numbers b ON b.id = (
SELECT MIN(id) FROM serial_numbers c WHERE c.id > a.id
)
WHERE b.id - a.id > 1;
- 子查询
SELECT MIN(id) FROM ... WHERE c.id > a.id模拟了LEAD()行为 - 必须给
id字段建索引，否则嵌套子查询会 O(n²) 扫描 - 如果最大 ID 后还有预期编号（比如业务规定应到 200），这个写法查不到“尾部缺口”，需额外判断
MAX(id)
真正麻烦的不是语法，而是序列号本身是否允许重复或跳变——比如日志流水号可能因重试产生重复，而设备上报 ID 可能本就非严格递增。先确认业务规则再选检测逻辑，比调通 SQL 更关键。
