利用SQL Anti-Join快速筛选未下单用户

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 是唯一能守住数据语义底线的写法。