LEFT ANTI JOIN是Hive、Spark SQL等大数据引擎原生支持的差集操作语法，语义清晰且性能更优；MySQL/PostgreSQL用户应改用NOT EXISTS以确保NULL安全与索引友好。
ANTI JOIN 不是标准 SQL 关键字，但 LEFT ANTI JOIN 是主流引擎的优化语法
大多数关系型数据库（如 MySQL、PostgreSQL）本身不支持 LEFT ANTI JOIN 作为独立语法，但它在 Hive、Spark SQL、Trino 等大数据引擎中是原生支持的，并且语义清晰、执行计划更优。它的作用就是「查左表有、右表无的记录」，即标准差集 A − B。如果你用的是这些引擎，直接写 LEFT ANTI JOIN 比手写 NOT EXISTS 或 LEFT JOIN + IS NULL 更直观、更少出错。
LEFT ANTI JOIN 的正确写法与常见误写
它不是 LEFT JOIN ... WHERE right_col IS NULL 的简写，而是独立连接类型，不返回右表字段，也不允许在 WHERE 中加额外条件——所有逻辑必须塞进 ON 子句里。
- ✅ 正确（Spark SQL / Trino）：
SELECT a.* FROM orders a LEFT ANTI JOIN returns b ON a.order_id = b.order_id;
- ❌ 错误：加
WHERE b.order_id IS NULL——LEFT ANTI JOIN已隐含该逻辑，再加会报错或被忽略 - ❌ 错误：漏掉
ON条件，或只写ON a.id = b.id却没确保b.id非空 —— 若右表该字段含NULL，可能意外排除有效匹配 - ❌ 错误：在
ON中对字段用函数，如ON UPPER(a.email) = UPPER(b.email)—— 大多数引擎不支持函数索引下推，导致全表扫描
MySQL / PostgreSQL 用户别硬套 LEFT ANTI JOIN，改用 NOT EXISTS 更稳
MySQL 8.0+ 和 PostgreSQL 虽支持 EXCEPT，但要求列数/类型/顺序严格一致，实际场景常因字段多、别名杂、NULL 处理难而弃用。相比之下，NOT EXISTS 语义明确、索引友好、NULL 安全：
-
NOT EXISTS不依赖右表字段是否为NULL，避免了LEFT JOIN + IS NULL在左表连接字段为NULL时的误判问题 - 子查询里必须写相关条件，例如
WHERE b.user_id = a.user_id，缺了就变成全量扫描 - 右表匹配字段（如
returns.order_id）一定要有索引，否则性能断崖式下跌 - 复合键场景下，
ON或子查询的WHERE必须完整列出所有字段，不能只写一部分
最容易被忽略的点：NULL 值在差集逻辑中的三重陷阱
差集查询真正翻车的地方，往往不在语法，而在数据本身：
- 用
NOT IN (SELECT ...)时，只要右表子查询结果里任意一个id是NULL，整个条件恒为UNKNOWN，结果为空——这是最隐蔽的静默失败 - 用
LEFT JOIN时，若右表关联字段允许NULL，且你又拿它做ON条件（比如ON a.ref_id = b.id，而b.id可空），那么(1, NULL)和(1, NULL)实际不匹配（SQL 中NULL = NULL为 false） - 用
COALESCE统一NULL表示虽可行，但会破坏索引使用；更稳妥的做法是过滤掉右表的NULL值：SELECT id FROM b WHERE id IS NOT NULL
