优先用NOT EXISTS定位缺失连续编号，因其语义清晰、索引友好且不受NULL影响；避免使用NOT IN，因子查询含NULL会导致结果为空；大范围缺失可先用MIN/MAX缩小边界，再结合递归CTE或generate_series辅助。
子查询如何定位缺失的连续编号
SQL 里没有内置“找断号”函数，但用子查询配合 NOT EXISTS 或 LEFT JOIN 能高效识别缺失值。关键不是生成完整序列，而是检查“某个编号是否存在”，避免全量构造大范围数字表带来的性能问题。
- 优先用
NOT EXISTS：语义清晰、索引友好，尤其当主表有id索引时，执行计划通常走 index lookup - 别用
NOT IN (SELECT ...)：若子查询返回NULL，整条语句结果为空——这是最常踩的坑 - 如果缺失范围很大（比如查 1~100000 中缺哪些），先用
(SELECT MIN(id), MAX(id) FROM t)缩小边界，再结合递归 CTE 或数字生成器（如 PostgreSQL 的generate_series）辅助，但多数业务场景只需“第一个断点”或“前几个断号”，没必要全量扫描
MySQL 8.0+ 中用 ROW_NUMBER() 检测断号更直观
如果你的表本身无序，但想按逻辑顺序（比如时间、插入顺序）判断编号是否连续，ROW_NUMBER() 是比自连接更稳的选择。它把原始数据打上“应有编号”，再和实际字段比对。
SELECT rn AS expected_id, id AS actual_id FROM ( SELECT id, ROW_NUMBER() OVER (ORDER BY id) AS rn FROM orders WHERE status = 'completed' ) t WHERE id != rn;
-
ORDER BY id是关键：确保行号按你关心的顺序生成；若按时间排序，就写ORDER BY created_at - 该方法天然跳过重复
id或NULL值（ROW_NUMBER()不跳过，但WHERE条件会暴露错位） - 注意：MySQL 5.7 不支持窗口函数，此时退回
NOT EXISTS方案更可靠
PostgreSQL 中用 generate_series 配合子查询查全部断号
当明确知道编号上下界（比如订单号从 10001 到 10500），且需要列出所有缺失值时，generate_series + NOT EXISTS 组合最直接。
SELECT s.n AS missing_id FROM generate_series(10001, 10500) AS s(n) WHERE NOT EXISTS ( SELECT 1 FROM orders WHERE id = s.n );
- 务必给
orders.id加索引，否则每次NOT EXISTS都是全表扫描 - 不要盲目扩大
generate_series范围——查 1~1000000 可能慢到超时；先用SELECT MIN(id), MAX(id) FROM orders拿真实边界 - 若表有分区（如按月分表），且缺失发生在某一分区，记得在子查询中加分区条件，避免跨分区扫描
WHERE 子句中嵌套子查询导致性能骤降的典型表现
常见错误是把子查询写成标量子查询（SELECT ... WHERE id > (SELECT MAX(x) FROM y)），尤其当它出现在 WHERE 中且未被优化器重写时，可能对每行都执行一次子查询。
- 检测方式：看
EXPLAIN输出中是否有DEPENDENT SUBQUERY，如果有，基本就是逐行执行 - 替代方案：把子查询提前算好，用变量或
WITH子句缓存结果，例如WITH max_val AS (SELECT MAX(id) FROM orders) SELECT * FROM logs WHERE log_id > (SELECT * FROM max_val) - 另一个陷阱：
IN (SELECT ...)在 MySQL 中可能退化为DEPENDENT SUBQUERY，改用JOIN或EXISTS更安全
真正卡住的往往不是语法，而是没意识到子查询在不同位置（SELECT 列、WHERE 条件、FROM 子句）的执行时机差异，以及数据库对 NULL 和空集的处理逻辑。
