干后端这么久，IN和EXISTS谁更好用这件事，一直也没吵个明白。

一部分老开发认为但凡关联子查询，直接上 EXISTS，IN 碰都别碰； 还有不少人持反对意见，本地测两条语句速度没差，觉得网上说的都是夸大其词，没必要刻意改代码。

两边都说自己实操没问题，各执一词，搞得新人完全分不清说的对。

我前阵子线上刚好踩过一次IN的坑，接口直接告警超时，改写成EXISTS瞬间恢复，今天不说教科书理论，就拿真实业务场景随便聊聊两者真实差距。

现场实测同需求，速度差几十倍

拿最常见的需求举例：筛选出过订单的用户。 用户表十万条，订单表三百万条，两张表关联字段都建了索引。

随手写的IN版本：

SELECT id,name FROM user_info 
WHERE id IN (SELECT user_id FROM order_pay);

放到生产环境一跑，几十秒拿不出结果，监控里数据库CPU直接拉满，接口超时报错。

换成EXISTS之后：

SELECT id,name FROM user_info u
WHERE EXISTS (
    SELECT 1 FROM order_pay o 
    WHERE o.user_id = u.id
);

毫秒级返回，负载一点波动都没有。

需求完全一样，索引齐全，性能却天差地别，根源是两者执行顺序完全相反。

它们执行逻辑是什么样的

先说IN的执行方式：数据库会优先跑完括号里的子查询。 也就是先把三百万订单的user_id全部查出来，堆在内存里做成集合，再循环用户表每一行数据挨个匹配。

数据少的时候内存压力小，感知不出卡顿；一旦子查询返回几万、几十万数据，内存占用暴涨，优化器还会直接放弃索引走全表扫描，慢是必然的。

再看EXISTS，先循环外层用户表，取单条用户ID去订单表匹配索引，只要找到一条对应数据就立刻停止检索，不会完整遍历整张订单表。 不用一次性加载海量数据，匹配即终止，天然适合大表关联。

为什么本地测试看不出问题？

这也是绝大多数人产生分歧的核心原因。 本地、测试环境数据量少，子查询返回的ID集合很小，IN带来的性能损耗可以忽略不计，跑起来自然没区别。

可一旦上线数据日积月累，表体量上来，之前埋下的隐患直接爆发，接口超时、数据库告警全找上门了。很多人都是上线踩坑之后，才回头整改所有IN子查询。

两个极易忽略的隐藏问题

1. IN集合包含NULL，查询直接无返回结果

SELECT * FROM user_info WHERE id IN (1,2,null);

报表统计、对账逻辑里经常出现这类隐性bug，排查半天才能定位，EXISTS完全不存在该问题。

2. 子查询返回数据量大，IN直接失效索引 IN后匹配数据过多，MySQL会判断走索引收益低，主动切换成全表扫描，数据库负载瞬间飙升；EXISTS依靠关联字段索引，不受子表数据量影响。

日常开发简单区分标准

能用IN的场景：只有固定枚举数值

SELECT * FROM user WHERE status IN (1,2,3);

必须替换成EXISTS，只要子查询关联另一张数据表 分页列表、后台报表、定时统计、多表关联筛选，全部统一改成EXISTS写法。

通用改写模板，直接复制使用：

SELECT * FROM A a
WHERE EXISTS (
    SELECT 1 FROM B b 
    WHERE b.aid = a.id
);

子查询只写SELECT 1，不用查询字段，减少磁盘读取开销，是线上通用写法。

最后总结

不用一刀切否定IN，也不用盲目吹捧EXISTS。 少量固定值筛选，IN写着简洁省事；只要涉及多表子查询，优先选EXISTS，能避开绝大多数线上慢查询故障。

阅读原文：https://mp.weixin.qq.com/s/30AH_dk1LUvmMamwA2kGZQ