IN 和 EXISTS 查询的区别是什么？
核心区别在于驱动表 和判断逻辑：
· IN：先执行子查询，将结果集物化 （生成临时表），再拿外层表的每一条记录去和这个临时表匹配。外层表驱动内层表 。
· EXISTS：先执行外层查询 ，每扫描外层一条记录，就代入子查询 去判断条件是否为真（返回TRUE/FALSE）。内层表驱动外层表（子查询表上若有索引，每次判断极快）。
通俗记忆：
· IN 适合子查询结果集小的场景（小表驱动大表）。
· EXISTS 适合外层结果集小，且子查询能走索引的场景（大表驱动小表）。
为什么使用 IN 进行子查询，性能会很差？
在MySQL 5.6及之前的老版本中，IN子查询有两大硬伤：
-
不自动走索引：子查询结果会被物化成内部临时表（不建索引），外层每扫一行，都要在这个无索引的临时表里做全表扫描 ，复杂度O(n²)。
-
无法下推索引：即使子查询自身表有索引，但物化后索引失效，本质是用内存/磁盘临时表替代了索引树。
转折：MySQL 5.6+引入了半连接 （Semi-Join）优化和物化（Materialization）策略，会自动给临时表建哈希索引，大部分场景已优化。但如果子查询包含GROUP BY、DISTINCT或UNION，优化器会退化为依赖子查询（DEPENDENT SUBQUERY），外层每行执行一次，性能炸裂。
IN 查询的缺陷是什么？
除了上述性能问题，还有三个工程致命伤：
· NULL值陷阱：WHERE id IN (SELECT id FROM b WHERE condition)，若子查询结果包含NULL，IN会返回UNKNOWN，导致整个结果集空集（除非你写了IN (1,2,NULL)）。业务上极难排查。
· 结果集膨胀风险：子查询如果返回上万条ID，SQL语句长度超限（max_allowed_packet），且优化器会放弃索引走全表扫描（超过eq_range_index_dive_limit阈值）。
总结
"IN和EXISTS本质是驱动顺序不同。
IN适合子查询小、外层大的场景；
EXISTS适合子查询大、外层小的场景。
IN的性能差主要源于5.6前会生成无索引临时表，导致全表扫描；而它的缺陷除了性能，还有NULL逻辑陷阱和大结果集撑爆SQL长度的风险。所以我们在生产环境，通常将IN子查询改写成JOIN或拆成两次查询，把控制权交给应用层。"