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在集合运算里根本不算“值”。
