left join + where 右表主键 is null 是查找左表有而右表无记录的最直接可靠方式；必须用右表主键或not null字段判空，避免误用可空字段导致错判，并需为右表关联字段建索引以保障性能。

LEFT JOIN + WHERE IS NULL 是最直接的写法

要查主表有但明细表没有匹配记录的数据，本质是找“左表有、右表空”的行。用 LEFT JOIN 连接后，在 WHERE 子句里筛出明细表字段为 NULL 的行即可。注意不能在 ON 条件里加明细表的非空限制（比如 detail.status = 'active'），否则会把本该被筛掉的行提前过滤掉。

常见错误是写成 INNER JOIN 或漏掉 WHERE 条件，结果返回的是“都有”的数据，完全反了。

• LEFT JOIN 必须写在主表之后，明细表在右边
• WHERE detail.id IS NULL 中的 detail.id 要选明细表里**定义为 NOT NULL 的字段**（通常是主键或非空外键），避免误判
• 如果明细表有多个关联条件（比如同时按 order_id 和 tenant_id 关联），ON 里必须全部写上，WHERE 仍只判 NULL

NOT EXISTS 更安全，尤其涉及明细表带条件筛选时

当你要查“主表存在，且明细表中**没有任何满足某条件**的记录”时，NOT EXISTS 比 LEFT JOIN 更可靠。它天然规避了 LEFT JOIN 在明细表有多条匹配时产生笛卡尔膨胀的问题，也避免因明细表条件写错位置导致逻辑偏差。

例如：查“没生成过成功账单的订单”，明细表 bill 里可能有失败、草稿等多条记录，但只要有一条 status = 'success' 就不该被选出 —— 这种场景用 NOT EXISTS 最干净。

• NOT EXISTS 子查询里用相关子查询，如 WHERE b.order_id = o.id AND b.status = 'success'
• 子查询不用 SELECT *，写 SELECT 1 即可，语义清晰且数据库优化器更易处理
• 注意别漏掉关联字段的等值条件，否则变成全表扫描

NOT IN 要小心 NULL，生产环境慎用

NOT IN (subquery) 看似简洁，但只要子查询结果里任意一行的字段值为 NULL，整个表达式就恒为 UNKNOWN，最终查不到任何数据 —— 这是 SQL 三值逻辑的经典陷阱。

即使你确认明细表那个字段设了 NOT NULL，也要提防关联字段本身在 JOIN 过程中因缺失而变成 NULL，或者子查询里不小心 SELECT 了允许为空的字段。

• 除非你能 100% 保证子查询返回结果中不含 NULL，否则不要用 NOT IN
• 如果非要硬上，得显式过滤：NOT IN (SELECT id FROM detail WHERE id IS NOT NULL)
• 多数主流数据库（PostgreSQL、SQL Server、Oracle）对 NOT IN 的 NULL 行为一致；MySQL 在某些老版本下表现略有差异，更不可靠

性能差异和索引建议

三种写法在执行计划上可能走不同路径：LEFT JOIN 常触发哈希连接或嵌套循环，NOT EXISTS 多走半连接（semi-join）或反连接（anti-join），NOT IN 则容易退化为全表扫描。

关键不是语法选哪个，而是看数据库是否能在明细表的关联字段上命中索引。比如主表 orders.id 和明细表 bill.order_id 都要有索引，否则无论怎么写都慢。

• 优先给明细表的外键字段建索引，例如 CREATE INDEX idx_bill_order_id ON bill(order_id)
• 如果用 NOT EXISTS 并带额外条件（如 status = 'success'），考虑复合索引：(order_id, status)
• PostgreSQL 对 NOT EXISTS 优化较好；MySQL 8.0+ 对 LEFT JOIN ... IS NULL 也做了不少改进，但老版本仍建议压测验证

实际写的时候，先跑 EXPLAIN 看执行计划，重点关注是否走了索引、有没有临时表或文件排序 —— 语法对了，不代表性能就对了。