MySQL不支持MINUS，需用LEFT JOIN ... IS NULL模拟；PostgreSQL/Oracle用EXCEPT更可靠，语义统一且自动去重；NOT EXISTS在复杂条件差集场景下更精准可控。
MySQL 不支持 MINUS，直接写会报错 ERROR 1064；PostgreSQL 和 Oracle 支持，但语义和 LEFT JOIN ... IS NULL 不完全等价——尤其在重复值、NULL 处理上容易出错。
MySQL 中用 LEFT JOIN 求 A 表有而 B 表无的记录
这是最常用、最可控的方式。核心逻辑是：把 A 当主表左连 B，再筛掉 B 中能匹配上的行。
-
LEFT JOIN必须基于明确的关联字段（如id、user_id），且两边字段类型要严格一致，否则隐式转换可能导致漏匹配 - 过滤条件必须写成
WHERE b.id IS NULL，不能写WHERE b.id = NULL（SQL 中= NULL永远为 false） - 如果 B 表关联字段允许 NULL，而你又没加
IS NULL判断，结果可能混入本该排除的行 - 示例：查订单表中「客户不存在于客户表」的脏数据
SELECT a.* FROM 订单 a LEFT JOIN 客户 b ON a.客户id = b.客户id WHERE b.客户id IS NULL;
PostgreSQL / Oracle 用 EXCEPT（不是 MINUS）更安全
MINUS 是 Oracle 专属语法，PostgreSQL 只认 EXCEPT；二者都做集合差，但默认去重、不保留顺序、对 NULL 的处理统一为“相等”——这点比手写 JOIN 更可靠。
-
EXCEPT要求两个SELECT的列数、类型、顺序完全一致，否则直接报错，强迫你显式对齐字段 - 它自动去重，如果你需要保留重复行（比如日志表中同 ID 多次出现），就得改用
NOT EXISTS或LEFT JOIN - 不能在
EXCEPT左右子句里直接加ORDER BY，必须在外层套一层查询再排序 - 示例：找出 product 表有但 product2 表没有的
product_id
SELECT product_id FROM product EXCEPT SELECT product_id FROM product2;
多表差集时，NOT EXISTS 比 LEFT JOIN 更准
当你要判断“A 表某条记录，在 B 表中完全找不到任何匹配”，尤其是 B 表存在复合条件（如状态=生效、时间在范围内）时，NOT EXISTS 更直观、不易出错。
-
NOT EXISTS子查询里用相关子查询（引用外层 A 表字段），语义清晰：“对 A 的每一行，检查 B 是否存在满足条件的行” -
LEFT JOIN在 B 表有多条匹配时，会产生笛卡尔膨胀，即使加了IS NULL也可能因聚合或分组逻辑混乱而误判 - 注意子查询里别忘了加
WHERE条件过滤 B 表的有效范围，否则差集结果会偏大 - 示例：查过去 7 天内下单但从未付款成功的用户
SELECT DISTINCT u.user_id
FROM 用户 u
WHERE NOT EXISTS (
SELECT 1 FROM 订单 o
WHERE o.user_id = u.user_id
AND o.status = 'paid'
AND o.pay_time >= CURRENT_DATE - INTERVAL '7 days'
);三个表求差集，避免嵌套 UNION ALL + GROUP BY 的陷阱
网上有方案建议把三张表 UNION ALL 后按主键 GROUP BY，再 HAVING COUNT(*) = 1 得差集。这仅在“三表主键绝对不重叠”时才成立——现实中极难保证。
- 一旦某条记录在表 A 和表 C 中恰好有相同主键值，就会被错误排除
- 更稳妥的做法是分两步：先算 A 相对于 B 的差集，再用结果跟 C 做差（即嵌套
NOT EXISTS或两次LEFT JOIN） - 如果三表结构不同，强行
UNION ALL还得补NULL占位，字段对齐极易出错 - 真正适合
UNION ALL + GROUP BY的场景，是三张结构完全一致的归档表，且你只关心“哪条记录只出现在一张表里”
差集操作最容易被忽略的点，是 NULL 值参与关联时的三值逻辑——NULL = NULL 为 unknown，导致 JOIN 失效、EXCEPT 却把它当相等。实际写之前，务必用 SELECT * FROM 表 WHERE 字段 IS NULL 看一眼数据分布。
