IN子查询慢的根源在于DEPENDENT SUBQUERY（相关子查询），即子查询引用外层表字段导致对主表每行重复执行；需通过EXPLAIN确认select_type是否为DEPENDENT SUBQUERY，并检查type、rows及索引使用情况，而非盲目替换为EXISTS。
IN子查询慢，先看执行计划里有没有DEPENDENT SUBQUERY
不是所有IN都慢，真正拖垮性能的是相关子查询（correlated subquery）——即子查询里引用了外层表字段，比如WHERE t1.id IN (SELECT t2.ref_id FROM t2 WHERE t2.status = 'active' AND t2.owner_id = t1.user_id)。这种写法会让MySQL对t1的每一行都重执行一次子查询。
用EXPLAIN查执行计划，重点盯type列：如果子查询部分显示DEPENDENT SUBQUERY，或者rows预估数异常高（比如主表1万行，子查询预估扫描50万行），就说明它正在被反复执行。
- 确认是否真相关：去掉子查询里的外层引用字段，改成固定值再
EXPLAIN对比；如果DEPENDENT SUBQUERY消失，那问题根源就在这 - 别只盯着语法换EXISTS——没索引支撑的EXISTS照样全表扫
- 注意NULL语义：
IN遇到子查询返回NULL，整行直接被过滤掉；EXISTS不受影响，改写后结果可能不一致
大量静态ID列表（如传入1000+个ID）该用临时表还是分批？
当IN后面是程序传入的一长串ID（比如WHERE id IN (1,2,3,...,5000)），瓶颈不在逻辑，而在解析、网络包大小和优化器决策。
MySQL默认max_allowed_packet通常为4MB，拼接5000个整数很容易超限；Oracle硬性限制1000个值，SQL Server约2100个——超了直接报错。
- 优先选分批：每批≤999个ID（避开Oracle限制），用循环发多个
SELECT * FROM t WHERE id IN (...)，应用层合并结果。简单、可控、无需DBA权限 - 临时表更适合高频复用场景：比如同一个ID集合要查3张表，先
CREATE TEMPORARY TABLE tmp_ids (id BIGINT PRIMARY KEY)，再INSERT INTO tmp_ids VALUES (...)，后续全部JOIN tmp_ids - 别用
VALUES子句模拟：MySQL 8.0+支持SELECT * FROM t WHERE id IN (SELECT id FROM (VALUES (1),(2),...) AS v(id))，但实际性能不如临时表，且PG/Oracle兼容性差
把IN换成EXISTS时，这三步漏一步就更慢
把IN改成EXISTS不是字符串替换，关键在执行路径是否真的变短。
原写法：WHERE order_id IN (SELECT id FROM orders_log WHERE status = 'failed')；改成EXISTS后如果没做调整，可能反而更慢。
-
SELECT *或SELECT id必须改成SELECT 1：让优化器明确“只判存在”，避免字段解析开销 - 关联条件不能丢：子查询里必须有
WHERE orders_log.order_id = orders.id，否则变成笛卡尔积，比原IN还糟 - 检查索引：
orders_log.order_id字段必须有索引，否则EXISTS的“找到一个就停”优势失效，退化成全表扫
什么情况下IN反而比EXISTS快？
别一看到IN就想着换，有些场景它天生更优。
比如WHERE status IN ('draft','pending','reviewing')这种固定枚举值，或者子查询不相关且结果集小（EXISTS的逐行探查。
- 外层表小、内层表大但索引覆盖好：比如查100个用户，看他们是否在百万级日志表中有记录，
IN走哈希匹配可能比EXISTS嵌套循环快 - 子查询含
GROUP BY/LIMIT/UNION：这类逻辑无法直接塞进EXISTS，硬改会导致语义错误或性能雪崩 -
NOT IN慎换NOT EXISTS：前者天然过滤NULL，后者需额外IS NOT NULL判断，业务逻辑可能翻车
最终得靠EXPLAIN ANALYZE（PostgreSQL）或EXPLAIN FORMAT=JSON（MySQL 8.0+）看真实执行耗时，而不是凭经验拍板。
