not exists是首选，因其语义清晰、天然规避null干扰、性能更优且跨库一致；必须写相关子查询并确保右表连接字段有索引。
直接用 NOT EXISTS 或 LEFT JOIN ... WHERE right_table.join_key IS NULL，别碰 NOT IN——它在 orders.user_id 有 NULL 时必然返回空结果。
为什么 NOT EXISTS 是首选写法
语义最干净：只关心“是否存在匹配行”，不取值、不判重复、不惧 NULL。子查询里漏掉外层关联，结果就全错；右表缺索引，性能会断崖下跌。
-
SELECT u.id, u.name FROM users u WHERE NOT EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id)—— 必须写o.user_id = u.id，漏掉就变全表扫描 - 子查询用
SELECT 1，不是SELECT *或SELECT NULL；后者可能触发额外字段解析或隐式转换 - 确保
orders.user_id有索引，否则 MySQL/PostgreSQL 都可能放弃优化，退成嵌套循环 - 如果还要加业务条件（比如“近30天没下单”），直接塞进子查询的
WHERE：o.user_id = u.id AND o.created_at >= DATE_SUB(NOW(), INTERVAL 30 DAY)
LEFT JOIN + IS NULL 的关键细节
这写法直观，但判断位置和字段选择稍有偏差，结果就错。它依赖右表连接字段本身不能为 NULL，否则 IS NULL 无法区分“没匹配”和“匹配了但存了 NULL”。
- 正确写法：
SELECT u.* FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE o.user_id IS NULL—— 判的是o.user_id，不是o.id -
o.user_id IS NULL必须在WHERE，不能挪到ON里；否则逻辑变成“左表全保留 + 右表按条件过滤”，失去反连接意义 - 如果
orders.user_id允许NULL（比如没设NOT NULL约束），这个查询会把“本该匹配却因外键为NULL被漏掉”的用户也当成“未下单”，此时必须换NOT EXISTS - 连接条件只能是等值（
=），不能包函数（如COALESCE(o.user_id, 0) = u.id），否则索引失效，优化器大概率无法生成 Anti Join 计划
NOT IN 为什么必须绕开
不是它不能用，而是只要 SELECT user_id FROM orders 返回任意一个 NULL，整条 NOT IN 查询结果就为空——这是 SQL 三值逻辑的确定行为，不是 bug。
-
SELECT * FROM users WHERE id NOT IN (SELECT user_id FROM orders)—— 若orders表里有一行user_id IS NULL，结果恒为空 - 即使加
WHERE user_id IS NOT NULL，优化器仍难走索引，执行计划常是HashAggregate+ 全表扫描，大数据量下比NOT EXISTS慢数倍 - 子查询若含重复值（比如同一用户多笔订单），
NOT IN不报错但内部去重开销不可控；NOT EXISTS天然无视重复
真正容易被忽略的点是：右表连接字段是否允许 NULL，以及你是否真的控制了它的数据质量。很多线上库的外键字段没设 NOT NULL，表面看是“没订单”，实际可能是脏数据导致的 NULL 值干扰——这时 NOT EXISTS 是唯一能守住语义底线的写法。
