如何通过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 是首选写法

语义最干净：只关心“是否存在匹配行”，不取值、不判重复、不惧 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 是唯一能守住语义底线的写法。