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 看执行计划，重点关注是否走了索引、有没有临时表或文件排序 —— 语法对了，不代表性能就对了。
