LEFT JOIN + WHERE b.id IS NULL 是查找“A表有但B表没有”记录最通用直接的方法，需确保ON中写正确关联条件、WHERE中用IS NULL而非= NULL，并注意NULL值和字段类型一致性。
用 LEFT JOIN + WHERE IS NULL 找差集最可靠
直接结论：想从表 A 中找出“在表 B 里不存在”的记录，LEFT JOIN 配合 WHERE b.id IS NULL 是最通用、可读性最好、且能正确处理 NULL 值的方式。
常见错误是写成 WHERE b.id != a.id 或漏掉 IS NULL 判断——这会导致笛卡尔积式误匹配，结果完全不可信。
- 必须在
ON子句中写关联条件（比如a.id = b.id），不能挪到WHERE -
WHERE b.id IS NULL必须写在JOIN之后，否则会把外连接退化为内连接 - 如果关联字段可能为
NULL，需提前用COALESCE或IS NOT DISTINCT FROM（PostgreSQL）处理，否则NULL = NULL不成立
NOT EXISTS 比 LEFT JOIN 更安全的场景
当需要判断“表 A 的某条记录，在表 B 中没有任何一行满足复杂条件”时，NOT EXISTS 更直观也更难出错。它天然规避了 JOIN 可能导致的重复行问题。
例如：查所有“从未下过订单的用户”，而订单表有复合主键或需要多字段匹配：
SELECT * FROM users u WHERE NOT EXISTS ( SELECT 1 FROM orders o WHERE o.user_id = u.id AND o.status = 'paid' );
-
NOT EXISTS子查询不返回数据，只判断是否存在，性能通常不输LEFT JOIN - 子查询里不能引用外部列以外的别名（比如不能写
u.name在子查询SELECT里） - MySQL 8.0+ 和 PostgreSQL 对
NOT EXISTS优化很好；旧版 MySQL（5.7 及之前）在某些情况下可能比LEFT JOIN慢
慎用 EXCEPT / MINUS —— 兼容性与语义陷阱
EXCEPT（SQL Server、PostgreSQL）和 MINUS（Oracle）看起来最像“集合差”，但实际使用限制多、易踩坑。
- 两表字段数、类型、顺序必须严格一致，否则报错
column count does not match - 自动去重：即使表 A 有 10 条重复记录，
EXCEPT只返回 0 或 1 行，无法保留原始重复 - MySQL 完全不支持
EXCEPT，得用UNION ALL + GROUP BY + HAVING COUNT = 1曲线救国，非常繁琐 - 如果只想差一个字段（比如只比对
email），必须显式写出所有要比较的列，不能只写SELECT email FROM a EXCEPT SELECT email FROM b然后补其他字段——语法不允许
JOIN 条件写错导致差集为空的典型表现
执行完 LEFT JOIN ... WHERE b.id IS NULL 却返回空结果？大概率是 ON 条件本身就有逻辑错误。
比如：A 表用 user_id，B 表用 uid，却写成 ON a.user_id = b.user_id——这根本连不上，自然所有 b.id 都是 NULL，结果看似“全差集”，实则无效。
- 先单独跑
SELECT COUNT(*) FROM a JOIN b ON a.x = b.y，确认能连上合理数量的行 - 检查字段类型是否隐式转换（如
VARCHAR和INT比较，可能触发全表扫描或意外截断） - 区分
LEFT JOIN和RIGHT JOIN：差集方向反了，结果就完全相反
差集本质是逻辑否定，不是语法糖。写错一个等号、漏一个括号、忽略 NULL 语义，结果就不可信。动手前，先用小样本验证关联逻辑是否成立。
