EXISTS在大数据量下常比IN快，因其无需物化子查询结果集，而是逐行短路关联检查；而IN需全量构建集合再匹配，大结果集易引发内存溢出或全表扫描。
EXISTS 为什么在大数据量下常比 IN 快
不是 EXISTS 本身“快”，而是它在多数大数据场景中更不容易触发高开销操作。核心在于：EXISTS 不需要物化子查询结果集，而 IN 在子查询返回大量值时，必须先构造并存储整个集合，再逐行匹配。
典型瓶颈出现在子查询返回数万甚至数十万行时：IN 会把所有 customer_id 加载进内存（或临时哈希表），如果没做优化，还可能引发磁盘临时表、OOM 或全表扫描主表；EXISTS 则对主表每行只做一次索引探查，找到第一个匹配就停，不关心内层有多少行。
- MySQL 5.7 及更早版本几乎不会重写
IN子查询为半连接，基本按字面意思执行 - MySQL 8.0+ 对小结果集的
IN有物化优化，但对大子查询仍无实质改进 -
EXISTS的执行计划中type常为ref或eq_ref，而IN大结果集下容易退化为ALL或range扫描
什么时候 IN 反而更快
别被“EXISTS 更快”带偏——当子查询结果集很小（几十到几百行）、且主表很大但关联字段有索引时，IN 往往更优。这时数据库能用哈希查找快速过滤主表，比逐行驱动子查询更省事。
例如：SELECT * FROM orders WHERE customer_id IN (SELECT id FROM customers WHERE type = 'vip')，若 customers 表里只有 42 个 VIP，这个 IN 就比等价的 EXISTS 更快，因为 orders.customer_id 上通常有索引，可直接走 IN 的 range scan。
- 子查询是轻量配置表、状态枚举、或带强条件过滤的小结果集
- 主表数据量大，但
WHERE ... IN (...)能命中索引（如主键、唯一索引） - 子查询本身没有
NULL值，且你确认未来也不会加
NOT IN 是个危险陷阱，必须换 NOT EXISTS
NOT IN 不是慢的问题，是逻辑错误高发区。只要子查询任意一行的字段为 NULL（哪怕只有一条），整个表达式就判为 UNKNOWN，结果集直接为空——你查不到数据，EXPLAIN 看不出异常，日志里也无报错。
NOT EXISTS 完全不受 NULL 影响，语义清晰，且子查询仍可走索引。即使你当前表字段定义了 NOT NULL，只要未来某天加了允许空值的列或视图，NOT IN 就可能静默失效。
-
NOT IN (SELECT c2 FROM t2)→ 若t2.c2含NULL，结果恒为空 -
NOT EXISTS (SELECT 1 FROM t2 WHERE t2.c2 = t1.c2)→ 正常走索引，逻辑稳定 - 所有数据库（MySQL/PostgreSQL/Oracle/SQL Server）都遵循此三值逻辑，无法绕过
真正该盯住的不是语法，是执行计划
无论写 IN 还是 EXISTS，最终快不快，取决于优化器生成的执行计划。重点看三列：type（是否用了索引）、rows（预估扫描行数）、Extra（是否出现 Using temporary 或 Using filesort）。
实操建议：对关键查询，先跑 EXPLAIN FORMAT=TREE（MySQL 8.0+）或 EXPLAIN ANALYZE（PostgreSQL），对比两种写法的 rows 和实际耗时。别依赖经验法则，尤其当表结构、索引、数据分布变化后，原先快的写法可能变慢。
最容易被忽略的一点：EXISTS 子查询里漏写关联条件（比如少写了 WHERE b.id = a.id），会导致它变成无关联子查询——每次执行都扫全表，比 IN 还慢。这种错误在开发阶段难发现，上线后才暴露。
