NOT IN遇NULL返回空结果是SQL三值逻辑所致，因id!=NULL恒为UNKNOWN被WHERE过滤；应改用NOT EXISTS或LEFT JOIN IS NULL替代。
用 IN 和 NOT IN 做简单交集与差集，但要注意 NULL
直接用 IN 查交集、NOT IN 查差集最直观，但有个致命陷阱：只要子查询结果里有 NULL，整个 NOT IN 就返回空结果。比如：
SELECT name FROM users WHERE id NOT IN (SELECT user_id FROM orders);
如果 orders.user_id 里有 NULL，这条语句查不到任何数据——不是逻辑错，是 SQL 三值逻辑导致的。实际中订单表常有外键未填或允许 NULL，这点极易踩坑。
-
IN对NULL相对友好：匹配非 NULL 值仍有效，只是不匹配NULL本身 - 想用
NOT IN，必须显式过滤：SELECT user_id FROM orders WHERE user_id IS NOT NULL - 若不确定子查询是否含
NULL，优先换用NOT EXISTS
用 EXISTS 和 NOT EXISTS 更安全可靠
EXISTS 不受 NULL 干扰，语义也更贴近“是否存在关联记录”，适合主表大、子表小的场景（数据库可提前终止扫描）。交集写法：
SELECT * FROM users u WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id);
差集（用户无订单）：
SELECT * FROM users u WHERE NOT EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id);
-
EXISTS子查询里用SELECT 1即可，不关心具体字段，也不需要GROUP BY或去重 - 关联条件必须写在子查询的
WHERE里，不能只靠外部 JOIN - 性能上，若
orders.user_id有索引，NOT EXISTS通常比LEFT JOIN + IS NULL更快
用 INNER JOIN 和 LEFT JOIN 实现等价逻辑
JOIN 写法更符合集合直觉，且能顺便取关联字段。交集即内连接：
SELECT DISTINCT u.* FROM users u INNER JOIN orders o ON u.id = o.user_id;
差集即左连接后筛空：
SELECT u.* FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE o.user_id IS NULL;
-
INNER JOIN默认去重效果有限，若一对多关系（一个用户多笔订单），需加DISTINCT防重复 -
LEFT JOIN的IS NULL判定，必须检查连接字段（这里是o.user_id），而非主表字段 - 当主表和子表都很大时，JOIN 可能比
EXISTS更耗内存，尤其没索引时
MySQL 8.0+ 和 PostgreSQL 支持 INTERSECT/EXCEPT，但有硬限制
标准 SQL 的 INTERSECT 和 EXCEPT 看起来最干净：
SELECT id, name FROM users INTERSECT SELECT user_id, NULL FROM orders;
但实际用起来很受限：
- 两个查询的列数、类型、顺序必须严格一致；
NULL字段要显式补位（如上面的NULL） - MySQL 在 8.0.33 之前根本不支持
INTERSECT/EXCEPT，老版本直接报错 - PostgreSQL 支持，但
EXCEPT默认去重，如需保留重复行得写EXCEPT ALL - 执行计划未必最优，某些场景下优化器无法利用索引，反不如
EXISTS
真正要跨表做集合运算，先确认数据库版本和字段兼容性，再决定是否用这类语法——多数业务场景，NOT EXISTS 仍是更可控的选择。
