IN子查询在大数据量时变慢，因其难以利用索引，常导致每行主表重复执行子查询或生成临时表嵌套循环，且遇NULL时结果为UNKNOWN而丢数据；应优先用INNER JOIN替代，但需确保语义等价、过滤条件不遗漏，并注意去重。

为什么IN子查询在大数据量时会变慢？

因为IN子查询通常无法有效利用索引，尤其当右侧是子查询（如SELECT id FROM users WHERE status = 'active'）时，数据库往往要对主表每行都执行一次子查询，或转为临时表嵌套循环。更糟的是，如果子查询返回NULL，整个IN表达式结果直接为UNKNOWN，导致意外丢数据。

用INNER JOIN替代IN的典型写法和陷阱

把WHERE t1.id IN (SELECT t2.ref_id FROM t2 WHERE ...)改成JOIN，核心是确认语义等价：你只想要t1中那些在t2里有匹配记录的行。

• 必须用INNER JOIN，不是LEFT JOIN——后者会保留t1所有行，语义不同
• 连接条件要明确写成ON t1.id = t2.ref_id，不能漏掉t2的过滤条件（比如t2.status = 'active'），否则结果膨胀
• 如果原IN子查询可能返回重复ref_id，JOIN会导致t1行被重复展开，需加DISTINCT或改用EXISTS

示例：

SELECT DISTINCT t1.name<br>FROM orders t1<br>INNER JOIN customers t2 ON t1.customer_id = t2.id<br>WHERE t2.country = 'CN';

比WHERE t1.customer_id IN (SELECT id FROM customers WHERE country = 'CN')更可控、更容易走索引。

什么时候JOIN反而不如IN？

小结果集、静态值列表场景下，IN (1, 2, 3)比建临时表再JOIN更轻量；另外，如果子查询本身极快（比如查缓存表、带覆盖索引的单字段查询），且返回行数极少（JOIN还可能让执行计划变复杂。

• MySQL 8.0+ 对IN子查询做了半连接（semi-join）优化，部分场景已自动转为JOIN，不必手动改
• PostgreSQL 的IN在子查询返回常量时会做哈希过滤，性能接近JOIN
• SQL Server 中若子查询含TOP或ORDER BY，IN行为不可预测，必须用EXISTS或JOIN

比JOIN更稳妥的替代方案：EXISTS

当语义是“只要存在匹配就返回主表行”，且担心JOIN引发重复、又不愿写DISTINCT时，EXISTS通常比JOIN更准确、更易读、执行计划也更稳定。

• EXISTS天然去重，不放大主表行数
• 相关子查询中可引用主表字段（如EXISTS (SELECT 1 FROM t2 WHERE t2.ref_id = t1.id AND t2.created_at > t1.time)），JOIN做不到这点
• 某些情况下（如t2有复合索引(ref_id, created_at)），EXISTS能用上索引跳过扫描，而JOIN可能触发全表扫描

真正要换掉IN时，先看执行计划里的type（MySQL）或Node Type（PostgreSQL）——如果显示DEPENDENT SUBQUERY或Seq Scan on t2，才值得动手；否则可能白忙活。