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，才值得动手；否则可能白忙活。
