真正的问题来了：怎么精准定位序列里的每个断点？直接拿当前ID和上一行ID做减法，差值大于1就意味着中间有空洞。LAG()能给出上一个值，再用WHERE条件一筛，missing_start和missing_end就清清楚楚。相比之下，MIN()和MAX()只能告诉你序列从几到几，根本看不到具体缺了哪个号。
所以，靠谱的做法是用LAG()或LEAD()配合筛选条件，而不是光靠GROUP BY加上MIN()/MAX()去猜缺口。后者充其量算范围，前者才是逐点排查。
为什么不能只靠MIN()和MAX()找缺失序列号
这两个函数只告诉你序列整体范围，比如最小值是1、最大值是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相等表示单个缺失，不等则表示连续缺多个数字；另外，首行的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;
这个方案里，子查询模拟了LEAD()行为，但必须给id字段建索引，否则嵌套子查询会陷入O(n²)的灾难级扫描。还有个需要注意的地方：如果最大ID后还有预期编号（比如业务规定应该到200），这个写法查不到尾部缺口，需要额外判断MAX(id)。
不过话说回来，真正麻烦的往往不是SQL语法本身，而是序列号是否允许重复或跳变。比如日志流水号可能因重试产生重复，而设备上报ID可能本就非严格递增。先确认好业务规则再选择检测逻辑，比调通一句SQL要实在得多。
