LEFT JOIN + IS NULL 是唯一可靠方式，需配合 WHERE 右表主键 IS NULL 筛出左表独有记录；漏掉 WHERE 会返回全部左表数据，误判源于用可空字段而非主键判空，且必须确保连接字段类型一致并有索引。
LEFT JOIN + IS NULL 是唯一可靠方式
想从左表中筛出“在右表里完全没匹配上的记录”，不能只靠 LEFT JOIN，必须配合 WHERE 右表主键 IS NULL。很多人漏掉这一步，结果拿到的是全部左表数据（含已匹配的），根本不是“独有”。
原因很简单：LEFT JOIN 本身只是保证左表全量保留，右表字段填 NULL 表示无匹配——但这些 NULL 行不会自动过滤出来，得靠 WHERE 显式抓取。
- 右表连接字段必须是**可能为 NULL 的列**（通常是主键或唯一键），不能用
SELECT *后随便挑个非空字段判断 - 如果右表连接字段允许 NULL（比如某个外键列本身可空），
IS NULL会误判“本该匹配却因字段为空被当成未匹配”，此时应改用右表主键（如id）判断 - 别用
!=或<>判断 NULL，它们对 NULL 永远返回 false
典型写法：用右表主键 IS NULL 过滤
假设要查用户表 users 中“从未下过单”的人，订单表是 orders，关联字段是 orders.user_id：
SELECT u.* FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE o.id IS NULL;
关键点：
- 这里必须用
o.id IS NULL，而不是o.user_id IS NULL—— 因为user_id是外键，即使没订单也可能被设为 NULL（业务异常），而o.id是主键，只要没生成订单行，它就一定为 NULL - 如果
orders表没有主键，至少选一个带NOT NULL约束的字段（如created_at），但优先级低于主键 - 别在
ON子句里加额外条件（如AND o.status = 'paid'），那会改变 JOIN 语义；真要筛特定状态的“未下单”，应在WHERE之后再处理
容易踩的坑：INNER JOIN、NOT IN 和性能陷阱
有人试过 NOT IN (SELECT ...) 或 NOT EXISTS，虽然也能实现，但和 LEFT JOIN + IS NULL 有本质区别：
-
NOT IN遇到子查询结果含 NULL 会整个返回空集（三值逻辑问题），极难排查 -
INNER JOIN是反向操作，只能拿“共同存在”的数据，离“左表独有”更远 - 大表场景下，
LEFT JOIN如果没走索引，性能可能比NOT EXISTS差；但只要ON字段和右表被判断的字段都有索引（如orders(user_id, id)联合索引），效率通常足够 - MySQL 5.7+、PostgreSQL、SQL Server 都支持这种写法，SQLite 也 OK；但某些旧版 HiveQL 不支持
IS NULL在WHERE中引用右表字段，得换NOT EXISTS
验证是否真“独有”：加 COUNT 或 LIMIT 快速检查
上线前建议先粗略验证逻辑是否符合预期：
- 执行
SELECT COUNT(*) FROM users和SELECT COUNT(*) FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE o.id IS NULL，两个数相减应等于已下单用户数 - 加
LIMIT 5看几条样例，手动查其中某个id是否真不在orders表里（避免连接条件写错，比如把u.id = o.user_id写成u.id = o.id） - 如果结果为空但预期不为空，优先检查右表连接字段是否有索引，以及是否拼错了表别名（比如把
o.id写成orders.id导致报错或隐式转换）
最常被忽略的是连接字段的数据类型一致性——比如左表 id 是 BIGINT，右表 user_id 是 VARCHAR，即使值看起来一样，JOIN 也可能失败，导致全表都被判为“独有”。
