left join + where right_table.id is null 是查找“主表有、关联表无”记录最常用且稳妥的写法，需确保连接字段类型一致、索引存在，并避免在where中对右表字段用函数；not exists更安全，尤其当关联字段可能为null时。
LEFT JOIN + IS NULL 是最常用也最稳妥的写法
查“主表有、关联表没有”的记录，必须用 LEFT JOIN 配合 WHERE right_table.id IS NULL。写成 = NULL 会永远不返回结果，因为 SQL 中 NULL = NULL 是未知（UNKNOWN），不是真值。
实操建议：
- ON 条件里字段类型要严格一致，比如
orders.user_id是VARCHAR，但users.id是INT，隐式转换可能让匹配失败却看不出原因 -
WHERE子句里别对右表字段用函数，例如WHERE COALESCE(u.id, 0) = 0，这会让索引失效 - 在关联字段上建索引能明显提速，尤其是
users.id和orders.user_id这类高频连接键
示例：
SELECT o.order_id, o.user_id<br>FROM orders o<br>LEFT JOIN users u ON o.user_id = u.id<br>WHERE u.id IS NULL;
NOT EXISTS 更安全，尤其当关联字段可能为 NULL
如果 users.id 允许为 NULL，LEFT JOIN 可能误判：哪怕右表有匹配行，只要连接键是 NULL，u.id IS NULL 就成立，导致假阳性。而 NOT EXISTS 不依赖连接字段的 NULL 处理逻辑，语义更干净。
实操建议：
- 子查询中必须写相关条件，比如
WHERE pc.countryid = c.countryid，漏掉就变成全表扫描+恒真/恒假 - 子查询里用
SELECT 1而不是SELECT *，减少数据搬运开销 - 若子查询字段没索引，性能会断崖下跌；确保
pc.countryid有索引
示例：
SELECT c.countryid<br>FROM tblcountry c<br>WHERE NOT EXISTS (<br> SELECT 1<br> FROM tblprojectcountry pc<br> WHERE pc.countryid = c.countryid<br>);
别用 NOT IN，除非你明确处理了 NULL
NOT IN 看似简洁，但只要子查询结果里有一个 NULL，整条 WHERE 判定就是 UNKNOWN，该行被过滤——最终可能一行都不返回，即使存在大量明确不匹配的记录。
常见错误现象：
- 查了半天没结果，其实是因为
orders.user_id里混着NULL值 - 换测试环境就出问题，因为生产数据含
NULL，测试库没有
如果非要用 NOT IN，必须显式排除：
WHERE user_id NOT IN (<br> SELECT user_id FROM orders WHERE user_id IS NOT NULL<br>)
FULL OUTER JOIN 用于双向比对，MySQL 需模拟
当你需要同时看到“左表有但右表无”和“右表有但左表无”的记录（比如核对两个系统客户 ID 是否一致），FULL OUTER JOIN 最直接。但 MySQL 不支持，得用 UNION ALL 拼两个 LEFT JOIN。
实操要点：
- 左右查询必须列数、类型、顺序完全一致，否则
UNION报错 - 别用
*，显式写字段名，避免因表结构变化导致列错位 - 两个
LEFT JOIN的WHERE条件要对称：一个筛right_table.id IS NULL，另一个筛left_table.id IS NULL
示例（PostgreSQL）：
SELECT 'only_in_orders' AS source, order_id, NULL AS user_id<br>FROM orders o<br>LEFT JOIN users u ON o.user_id = u.id<br>WHERE u.id IS NULL<br>UNION ALL<br>SELECT 'only_in_users', NULL, id<br>FROM users u<br>LEFT JOIN orders o ON u.id = o.user_id<br>WHERE o.order_id IS NULL;容易被忽略的一点是：缺失值检查往往不是一次性动作，而是嵌入在 ETL 或数据质量监控流水线里。这时候，
NOT EXISTS 的稳定性和可预测性，比 LEFT JOIN 的直观性更重要——尤其当关联字段本身允许 NULL 时，它带来的误报很难被日志或告警覆盖到。
