NOT EXISTS是首选，因其语义清晰、天然规避NULL干扰、性能更优且跨库一致；必须写相关子查询并确保右表连接字段有索引。
对这句话稍微展开说说。要是真在实际业务里碰见“找出所有未下单的用户”，直接用 NOT EXISTS 或者 LEFT JOIN ... WHERE right_table.join_key IS NULL 就行。千万别图省事去碰 NOT IN，只要 orders.user_id 里头有那么一个 NULL，整条查询立刻就歇菜，返回空结果。
为什么 NOT EXISTS 是首选写法
先说最干净的做法。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 的关键细节
这写法很直观，但判断位置和字段选择稍有不慎，结果就错。它的原理是用左连接把所有用户都拉出来，然后只保留那些没有匹配到订单的用户。但这里面有几个关键点必须卡死。
- 正确写法：
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.id如果允许为NULL（比如某些业务场景），那判它就分不清是没匹配上还是匹配上了但字段是空。 o.user_id IS NULL必须写在WHERE里，千万不能挪到ON里。否则逻辑就变成“左表全保留 + 右表按条件过滤”，那样就失去了反连接的意义，结果会把所有用户都返回。- 如果
orders.user_id字段允许为NULL（比如建表时没有加NOT 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 是唯一能守住数据语义底线的写法。
