IN子查询在大数据量下易变慢，因其常被优化器转为物化临时表+嵌套循环，若子查询结果大或无索引则触发全表扫描；且含NULL时表达式恒为FALSE，干扰执行计划并引发逻辑错误。

为什么IN子查询在大数据量下容易变慢IN子查询（尤其是右侧为子查询时）在 MySQL、PostgreSQL 等引擎中，常被优化器转为「物化临时表 + 嵌套循环」，若子查询结果集大或未走索引，就会触发全表扫描。更关键的是：当IN子句中包含NULL值，整个表达式可能意外返回空结果（SQL 标准规定 expr IN (..., NULL, ...) 永远不为 TRUE），这不仅影响逻辑，还干扰优化器选择执行计划。

常见错误现象包括：SELECT * FROM orders WHERE customer_id IN (SELECT id FROM customers WHERE region = 'CN') 执行超时，而customers表明明有region索引——问题往往出在子查询未去重、外层无法利用索引下推，或优化器误判为“先算子查询再过滤”。

用EXISTS重写时必须注意的三件事EXISTS天然适合“存在性判断”，且多数引擎能将关联条件下沉到内层查询，更容易命中索引。

• 必须写成相关子查询：内层SELECT里要引用外层表字段，例如EXISTS (SELECT 1 FROM customers c WHERE c.id = o.customer_id AND c.region = 'CN')；写成SELECT 1 FROM customers WHERE region = 'CN'（无关联）就退化为半连接，失去优化意义
• EXISTS不关心内层返回多少行，只看是否至少一行满足；因此内层SELECT写SELECT 1或SELECT NULL即可，避免SELECT *带来额外列传输开销
• 如果原IN语义允许重复匹配（比如统计订单数），改用EXISTS后需确认业务是否仍等价——EXISTS只判断“有无”，不改变外层行数，这点和IN一致；但若原逻辑依赖子查询去重行为，则需额外加DISTINCT或调整设计

什么时候该选JOIN而不是EXISTS 当需要从子查询中取字段、或需对匹配结果做聚合/排序时，JOIN更直接。但要注意：用INNER JOIN会自动去重外层重复行（若外键非唯一），而IN不会——这是最易踩的语义坑。

示例场景：查所有有订单的客户姓名及首单时间。

SELECT DISTINCT c.name, MIN(o.created_at)
FROM customers c
INNER JOIN orders o ON c.id = o.customer_id
WHERE c.region = 'CN'
GROUP BY c.name

这里不能用EXISTS，因为要取o.created_at；也不能简单用IN，因为要聚合。同时注意：INNER JOIN会排除无订单客户，和IN语义一致；但若误用LEFT JOIN + WHERE o.id IS NOT NULL，性能反而更差（先全连接再过滤）。

MySQL 8.0+ 和 PostgreSQL 的实际差异点 MySQL 在 8.0 后对IN子查询做了物化优化（materialization），但仅当子查询不含外层引用、且结果集较小时才启用；一旦带关联，仍倾向走DEPENDENT SUBQUERY，此时EXISTS几乎总是更稳。

PostgreSQL 则对IN和EXISTS处理更统一，优化器常将二者等价重写，但仍有例外：当子查询含LIMIT或OFFSET时，IN可能报错（“subquery must return only one column”），而EXISTS不受限。

一个常被忽略的细节：NOT IN遇到NULL直接失效，而NOT EXISTS完全不受NULL影响——只要业务涉及否定逻辑，优先用NOT EXISTS，别碰NOT IN。