查外键缺失的孤立记录时，应优先用 LEFT JOIN + WHERE 右表字段 IS NULL，而非 NOT IN；因 NOT IN 遇子表外键含 NULL 会返回空结果，而 LEFT JOIN 语义清晰、不受 NULL 干扰，且能通过索引优化性能。
查外键缺失的孤立记录时，LEFT JOIN 比 NOT IN 更可靠
直接用 NOT IN 查“不在主表里的子表记录”容易漏数据，因为只要子表外键列有 NULL，整条 NOT IN 就返回空结果集。这是 SQL 三值逻辑的典型坑。
正确做法是用 LEFT JOIN 关联主表，再筛出 JOIN 结果为 NULL 的行：
SELECT child.id, child.user_id FROM orders child LEFT JOIN users parent ON child.user_id = parent.id WHERE parent.id IS NULL;
-
LEFT JOIN不受NULL干扰，语义清晰：找那些“想连却连不上”的记录 - 确保
child.user_id和parent.id类型一致，否则隐式转换可能让索引失效 - 如果
user_id是INT而id是BIGINT，MySQL 可能放弃使用索引
批量扫描多张子表时，避免写一堆重复 UNION ALL
当要检查 orders、comments、notifications 是否都存在无效 user_id，硬写三个 LEFT JOIN 查询再 UNION ALL 效率低、难维护。
更稳的方式是把待查子表和关联字段抽象成元数据，用动态 SQL 或应用层拼接（如 Python + psycopg2）：
tables_to_check = [
("orders", "user_id", "users", "id"),
("comments", "author_id", "users", "id"),
("notifications", "target_user_id", "users", "id")
]- 每组元组明确声明“哪张子表、哪个外键、关联哪张主表、主表哪个字段”，避免手误写错列名
- 执行前先确认各子表外键列都有索引；没索引的
LEFT JOIN会全表扫描，查千万级表直接卡死 - PostgreSQL 中可配合
EXPLAIN (ANALYZE)看是否真走了索引
EXISTS 和 NOT EXISTS 在大表反向校验时更省内存
当主表（如 users）远大于子表（如 profiles），且你想找“有用户但没档案”的记录，用 NOT EXISTS 比 LEFT JOIN ... IS NULL 更轻量：
SELECT u.id FROM users u WHERE NOT EXISTS ( SELECT 1 FROM profiles p WHERE p.user_id = u.id );
-
NOT EXISTS只需找到一个匹配就短路退出，不构造中间结果集，内存占用小 - 必须确保子查询中
p.user_id有索引，否则每次都要扫全表profiles - 注意别写成
NOT EXISTS (SELECT * ...)——*无意义，还可能被某些旧版 MySQL 解析出错
线上环境跑脏数据扫描前，务必加 LIMIT 和超时控制
脏数据查询本质是诊断性扫描，不是业务逻辑。一旦没加限制，在生产库上扫错表或条件漏写，可能拖垮整个实例。
- 任何手动执行的扫描 SQL 都应带
LIMIT 100，确认逻辑对了再删掉 - MySQL 客户端可用
SET SESSION max_execution_time = 30000;（单位毫秒）防长查询 - PostgreSQL 建议在会话开头设
SET statement_timeout = '30s'; - 不要依赖应用层超时——数据库连接可能已卡住，应用等不到响应
真正麻烦的不是查不出脏数据，而是查的过程锁了表、占满 I/O、触发主从延迟。这些约束看起来琐碎，但跳过一次，就可能半夜被叫醒。
