先说一个核心判断：“僵尸客户”这个词在数据库里并没有官方定义，它纯粹是业务场景下的概念——指那些注册了账号、生成了记录，却从未下过单的用户。那么，如何用 SQL 精准定位这批用户？关键不在于查询时间字段，而是要通过 customers 和 orders 两张表做关联判断。
什么是“僵尸客户”在 SQL 中的准确定义
不用想得太复杂。只要理清思路：客户表里每条记录对应一个用户，而订单表中只有真正下过单的用户才会留下记录。你需要做的，就是找出那些在订单表里“查无此人”的记录。
不少新手会直接写 WHERE order_date IS NULL——这是典型的思维定式。问题出在哪？从未下单的客户根本不会在 orders 表里产生任何行记录，你连 JOIN 都无法关联上，NULL 自然也不会凭空出现。
用 NOT EXISTS 比 LEFT JOIN 更安全
在实际项目中，NOT EXISTS 是最稳健的主力写法。它的语义非常清晰：“对每一个客户，去订单表里检查是否有匹配的订单记录”。相比 LEFT JOIN ... WHERE order_id IS NULL，它不依赖连接后是否生成空行，也不会被订单表中的脏数据或重复记录干扰。
操作时注意以下几点：
- 子查询里一定要把外层的
customer_id绑定进去，例如WHERE o.customer_id = c.customer_id - 子查询中的
SELECT 1就足够了，不用*或具体字段名，以减少额外消耗 orders.customer_id必须建立索引，否则数据量一大，性能会急剧下降
SELECT c.customer_id, c.email FROM customers c WHERE NOT EXISTS ( SELECT 1 FROM orders o WHERE o.customer_id = c.customer_id );
IN 子查询容易出错的两个坑
有些人习惯写 customer_id NOT IN (SELECT customer_id FROM orders)。这个写法存在两个致命隐患：
第一，如果 orders.customer_id 列中包含任何一个 NULL，整个 NOT IN 的结果集会直接变为空——因为 NOT IN 遇到 NULL 会判定为 UNKNOWN，然后所有行都会被过滤掉。这个坑在数据清洗不彻底的环境中非常常见。
第二，如果订单表中有同一个客户的多条订单，子查询会返回重复的 customer_id，IN 虽然不会报错，但执行效率会受到影响。
因此，除非你 100% 确认 orders.customer_id 既非空且已去重，否则不建议使用 NOT IN。
要不要加 LIMIT？什么时候加
线上查询僵尸客户时，通常不需要全量导出。大多数场景是抽样验证逻辑是否正确，或者运行测试方案是否有效。直接全表扫描可能会拖慢从库，甚至引发锁表。
推荐的做法：
- 在开发或测试环境中，先加上
LIMIT 100确认结果符合预期 - 在生产环境执行前，用
EXPLAIN确认查询走的是customers主键索引和orders.customer_id索引 - 如果需要导出全部数据，采用分页方案（如
LIMIT 10000 OFFSET 0）并配合循环，避免单次查询撑爆内存
说句实在的，真正棘手的不是 SQL 语法本身，而是业务上的判断：订单表中那些退款订单、测试订单、系统自动补单，到底算不算“有效购买”？这需要查阅业务文档，并非写个子查询就能解决的。
