left join + is null 是唯一可靠手段，用于无外键约束表的反向验证；必须用右表主键或外键字段判空，避免可空业务字段，复合主键需全字段is null，not exists更安全且对null免疫。
LEFT JOIN + IS NULL 是唯一可靠手段
没有外键约束的表，靠人工维护关联关系极易出错。此时 LEFT JOIN 配合 IS NULL 不是“一种方法”，而是事实标准——因为它是唯一直接基于数据值本身做反向验证的方式。
常见错误现象：用 INNER JOIN 查匹配记录，却误以为没查到就是缺失；其实只是连接逻辑天然过滤掉了不匹配行，根本看不到问题数据。
- 必须用
LEFT JOIN保留左表全部记录，右表无匹配时整行为 NULL - 判空字段必须是右表的主键或外键列（如
c.id），不能是可空业务字段（如c.name） - 若右表有复合主键（如
(region, code)），需同时判断r.region IS NULL AND r.code IS NULL
NOT EXISTS 检测无效外键更安全
无效外键指子表外键值在父表主键中查无对应，比如 orders.customer_id = 999 但 customers.id 中根本没有 999。这种数据通常源于手动插入、迁移遗漏或级联删除未启用。
NOT EXISTS 比 LEFT JOIN 更合适，因其语义直白、对 NULL 安全、执行计划更优，且避免 NOT IN 遇 NULL 返回空结果的陷阱。
- 正确写法：
SELECT o.id, o.customer_id FROM orders o WHERE NOT EXISTS (SELECT 1 FROM customers c WHERE c.id = o.customer_id) -
SELECT 1是惯用写法，比SELECT *更轻量，数据库优化器也认得这是存在性检查 - 子查询中必须用相关列（如
c.id = o.customer_id），否则变成非相关子查询，结果恒为真或假 - 若父表主键含 NULL，
NOT IN会整个返回空结果集——这是最常踩的坑
索引缺失会让 JOIN 检查变慢甚至卡住
子查询性能高度依赖索引。若父表主键未建索引（极少见），或子表外键列没索引，NOT EXISTS 可能触发全表扫描，查百万级订单表可能卡住。
- 务必确保父表被查字段（如
customers.id）有主键或唯一索引 - 子表外键字段（如
orders.customer_id）必须有普通索引，否则 LEFT JOIN 或子查询都会退化 - 用
EXPLAIN看执行计划：MySQL 中若出现type: ALL+Extra: Using where; Using join buffer，基本确认缺索引
多表联合查孤儿数据要慎用 UNION ALL
当一个主表被多个子表引用（如 users 同时被 orders、comments、favorites 引用），想查完全未被引用的用户，容易直接套用 UNION ALL 子查询。
这种写法可行，但要注意两点：一是 UNION ALL 不去重，若某用户在多个子表中都无记录，不会重复计数；二是若任一子表数据量极大，UNION ALL 临时结果集可能膨胀。
- 推荐写法：
SELECT u.id, u.name FROM users u LEFT JOIN (SELECT user_id FROM orders UNION ALL SELECT user_id FROM comments UNION ALL SELECT user_id FROM favorites) refs ON u.id = refs.user_id WHERE refs.user_id IS NULL - 更稳健的做法是分步查：先查
orders中存在的用户，再用NOT EXISTS排除，依次叠加，便于定位具体哪张子表漏了数据 - 别忽略中间表本身的外键有效性——比如
comments.user_id若本身指向不存在的用户，会污染整个联合结果
status 而非 id）会导致结果不可信，而这种错误在小数据集上还看不出来。
