最可靠的方式是用 NOT EXISTS 获取差集，因其语义清晰、不受 NULL 影响；NOT IN 遇 NULL 会返回空结果，LEFT JOIN + IS NULL 需确保右表关联字段非 NULL 且索引有效；MySQL 不支持 EXCEPT。
MySQL 用 NOT EXISTS 获取差集最可靠
直接用 LEFT JOIN ... IS NULL 或 NOT IN 容易出错，尤其当字段含 NULL 时。NOT EXISTS 是语义最清晰、行为最确定的方式。它明确表达“在 A 表中存在，但在 B 表中找不到匹配行”的逻辑，不依赖空值处理规则。
常见错误现象：NOT IN (SELECT ...) 遇到 B 表的列有任意一个 NULL，整个条件直接返回空结果——这是 SQL 三值逻辑导致的，不是 bug，但极易被忽略。
- 只对主键或非空唯一字段做差集比较最安全
- 若需比对多列，
NOT EXISTS子查询里必须用AND显式连接所有条件 - 确保子查询中的关联字段有索引，否则性能会断崖式下降
LEFT JOIN + IS NULL 写法及陷阱
这是直观、可读性高的写法，但必须严格满足两个前提：右表关联字段不能为 NULL，且 ON 条件中不能混用 OR 或函数（否则索引失效）。
典型误用：ON a.id = b.id AND b.status != 'deleted' —— 如果 b.status 允许 NULL，IS NULL 判断会漏掉本该算作“不存在”的行。
- 务必在
JOIN后加WHERE b.id IS NULL，而不是WHERE b.id = NULL（后者永远为 false） - 如果右表有多个匹配行，
LEFT JOIN会重复左表记录，需配合DISTINCT或GROUP BY - 在 MySQL 8.0+ 中，优化器对这种模式识别较好；5.7 及更早版本建议给
b.id加索引
用 EXCEPT？MySQL 不支持
MySQL 直到 8.0.31 仍不支持标准 SQL 的 EXCEPT 操作符。别在官方文档外看到别人写了 EXCEPT 就以为能用——那大概率是 PostgreSQL、SQL Server 或 SQLite 的语法混进来了。
强行模拟 EXCEPT 不仅冗长，还容易因去重逻辑（是否保留重复行）引发歧义。例如：
SELECT id, name FROM table_a UNION ALL SELECT id, name FROM table_b
和
SELECT id, name FROM table_a UNION SELECT id, name FROM table_b
行为完全不同，但都跟差集无关。
性能关键：别忘了加索引
差集查询本质是大量“查找不存在”的操作，没有索引时就是全表扫描嵌套，数据量过万就明显卡顿。
- 左表字段（如
a.user_id）不需要单独索引，但参与JOIN或子查询关联的字段必须有 - 右表的关联字段（如
b.user_id）强烈建议建 B+ 树索引，复合索引优先于单列索引 - 执行前一定用
EXPLAIN看type是否为ref或eq_ref，避免出现ALL
真正麻烦的从来不是语法怎么写，而是你查的那张表有没有被正确索引，以及你是否意识到 NULL 在集合运算里根本不算“值”。
