判断一条记录是查存否存在，最省事的询否写法是 SELECT EXISTS(SELECT 1 FROM users WHERE email = 'a@b.com')。这个语句返回 0 或 1，查存不返回具体数据，询否数据库找到第一条匹配就停，查存不会继续扫。询否很多人习惯写 SELECT COUNT(*) FROM users WHERE email = 'a@b.com'，查存然后拿返回值跟 0 比。询否逻辑上没错，查存代价是询否数据库得把符合条件的所有行都数一遍。表小的查存时候感觉不出来，几百万行、询否条件又只命中一两条时，查存差距就摆在那了。询否

我见过一个订单系统，查存用 COUNT(*) 判断用户当天有没有下过单，接口 QPS 一上来，慢查询日志里全是这条。换成 EXISTS 之后，同样的索引，响应时间从 40ms 掉到 2ms 以内。不是索引的问题，是 COUNT 本身要求全量计数，EXISTS 只要求“有没有”。

EXISTS 和 IN 不是一回事

关联查询里常有人写 WHERE id IN (SELECT user_id FROM orders WHERE amount > 100)。子查询结果集小的时候没问题，一旦 orders 表里符合条件的 user_id 有几十万个，MySQL 可能先把子查询物化成临时表，再拿外层每一行去比对。EXISTS 走的是另一条路：对外层的每一行，拿它的 id 去子查询里试一下，命中就返回 true。外层表小、子查询表大的场景，EXISTS 通常更稳。

不过也别迷信。MySQL 8.0 的优化器会把 IN 和 EXISTS 做半连接转换，实际执行计划可能跟你想的不一样。用 EXPLAIN 看一眼，比背规则靠谱。

代码里的“存在性判断”

应用层也经常干类似的事。比如注册时查邮箱是否已被占用：

SELECT id FROM users WHERE email = ? LIMIT 1

拿到结果判断是否为空。这跟 EXISTS 是一个思路——只取一条，不做计数。有些 ORM 框架提供 .exists() 方法，底层发的就是带 LIMIT 1 的查询或者 EXISTS 子句。别用 .count() > 0，那等于让数据库白干一遍计数的工作。

还有一种情况是判断“不存在才插入”。先 SELECT 再 INSERT 在并发下会出问题，两个请求同时查到不存在，然后都去插。正确做法是给字段加唯一索引，直接 INSERT，捕获唯一键冲突异常。查询是否存在这一步，在高并发写入场景里本来就不可靠。

NOT EXISTS 的坑

找“没有下过单的用户”，写法是 SELECT * FROM users u WHERE NOT EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id)。这没问题。但如果写成 WHERE u.id NOT IN (SELECT user_id FROM orders)，而 orders.user_id 允许为 NULL，结果会全部为空。SQL 的三值逻辑在这里咬人：NULL 参与 NOT IN 比较，结果既不是 true 也不是 false，是 unknown，整行被过滤掉。这个坑我踩过，排查了半天才发现子查询里有脏数据。

EXISTS 不受 NULL 影响，因为它只关心子查询有没有返回行，不拿值去比较。所以涉及可能为 NULL 的列，NOT EXISTS 比 NOT IN 安全。

什么时候不用 EXISTS

需要拿到具体数据的时候，当然不能用 EXISTS。还有一种情况：子查询和外层表没有关联条件，EXISTS 会退化成“子查询有没有结果”，跟外层每一行都无关，这时候它和 IN 的语义完全不同。写之前想清楚关联条件写没写对。

简单说，只问“有没有”，用 EXISTS 或 LIMIT 1。要计数、要数据，另说。数据库不会因为你写 COUNT 就少干活。

(责任编辑：综合)