LEFT JOIN + IS NULL 是查找未下单客户的最可靠方式，需以客户表为主表左连接订单表，并用 WHERE o.customer_id IS NULL 筛选；NOT IN 因 SQL 三值逻辑遇 NULL 恒返回空结果，必须规避。
用 LEFT JOIN + IS NULL 找出没订单的客户
直接用 LEFT JOIN 关联客户表和订单表，再筛选订单 ID 为 NULL 的记录，是最可靠、最易理解的方式。别用 NOT IN，它在订单表有 NULL 值时会返回空结果——这是线上查不到数据的常见原因。
假设客户表是 customers（主键 id），订单表是 orders（外键 customer_id）：
SELECT COUNT(*) FROM customers c LEFT JOIN orders o ON c.id = o.customer_id WHERE o.customer_id IS NULL;
-
LEFT JOIN确保所有客户都保留，哪怕没匹配到订单 -
WHERE o.customer_id IS NULL是关键：只有没关联上订单的客户，这一列才是NULL - 不要写
WHERE o.id IS NULL——如果订单表主键允许NULL（极少见），或你误用了别名，结果就错了
为什么 NOT IN 会失效
NOT IN 看起来简洁，但只要 orders.customer_id 里存在任意一个 NULL，整个查询就返回 0 行。SQL 中任何值与 NULL 比较都得 UNKNOWN，而 WHERE 只认 TRUE。
这个错误不会报错，只会静默返回错误结果，特别难排查。
- 错例：
SELECT COUNT(*) FROM customers WHERE id NOT IN (SELECT customer_id FROM orders); - 如果子查询结果含
NULL，外部NOT IN判定全部失效 - 即使加
WHERE customer_id IS NOT NULL也能修，但多一层嵌套，可读性和性能都不如LEFT JOIN
COUNT(*) vs COUNT(c.id) 在这种场景没区别
有人担心 LEFT JOIN 后用 COUNT(*) 会不会把 NULL 行也算进去？不会。COUNT(*) 统计的是结果集的行数，不是某列的非空值；而 WHERE 已经过滤出“没订单”的客户行，每行对应一个客户，所以 COUNT(*) 和 COUNT(c.id) 结果完全一致。
- 用
COUNT(*)更习惯，也更安全（不依赖某列是否为NOT NULL） - 别用
COUNT(o.customer_id)——那一列全是NULL，结果永远是 0
大数据量时注意索引
如果客户表百万级、订单表千万级，这个查询可能变慢。核心瓶颈通常在 orders.customer_id 上缺少索引。
- 确保
orders.customer_id有索引（通常是外键约束自动创建的，但别假设） - 检查执行计划：
EXPLAIN输出里type应为ref或eq_ref，而非ALL - 如果客户表本身很大且只查数量（不要客户详情），有些数据库（如 PostgreSQL）支持
EXISTS写法，但 MySQL 下LEFT JOIN通常更稳
真正容易被忽略的，是子查询中 NULL 值对 NOT IN 的破坏性影响——它不报错，也不警告，就 quietly 返回 0。上线前务必用含 NULL 的测试数据验证逻辑。
