IN子查询大数据量下性能差因全量构造内存集合并逐行比对，易超内存；MySQL 5.7前默认嵌套循环+临时表策略，I/O飙升；NULL致UNKNOWN、无法利用外层索引、子查询优化受限。
IN子查询在大数据量下性能差，不是语法问题，而是执行机制导致的——它会把子查询结果全量构造为内存集合，再逐行比对。数据一过万，就容易卡住甚至超内存。
为什么IN子查询在大数据量时变慢
MySQL（尤其是5.7及之前）对IN子查询默认走嵌套循环 + 临时表策略：外层每查一行，都要触发一次子查询；若子查询返回几十万行，就会生成巨大临时表，一旦超出tmp_table_size，立刻落盘，I/O飙升。
- 子查询含
NULL时，整个IN表达式可能返回UNKNOWN，导致意外空结果 -
IN (SELECT ...)无法利用外层索引做驱动，优化器常放弃使用索引 - 即使子查询字段有索引，MySQL也未必能下推到内层执行，尤其当子查询含
GROUP BY或ORDER BY时
用EXISTS替代IN的适用场景与限制
不是所有IN都能无脑换EXISTS，关键看语义是否等价、驱动方向是否合理。
- 当子查询表（内表）远大于主表（外表），且内表上有对应字段索引时，
EXISTS更优：它对外表逐行探测，命中即停，不构造全集 - 但若子查询本身很重（比如带聚合、多表JOIN），
EXISTS反而可能重复执行多次，此时不如先物化子查询结果 -
NOT IN必须换NOT EXISTS：前者遇到NULL直接失效，后者可正常走索引
示例：SELECT * FROM users u WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id AND o.status = 'paid') —— 这里orders(user_id)有索引才真正提速。
用临时表+JOIN彻底绕过IN机制
这是处理「固定大批量ID列表」（如导出后回查）最稳的方式，把不可控的IN变成可控的JOIN。
- 先建
CREATE TEMPORARY TABLE temp_ids (id BIGINT PRIMARY KEY)，显式加主键，避免全表扫描 - 批量插入用
INSERT INTO temp_ids VALUES (1),(2),(3),...,(10000)，单次最多1000–2000值，防SQL长度超限 - 主查询改写为
SELECT u.* FROM users u JOIN temp_ids t ON u.id = t.id，确保users.id也有索引 - 注意：临时表生命周期仅限当前连接，别忘了
DROP TEMPORARY TABLE temp_ids（虽连接断开会自动删）
分批+UNION ALL是最后兜底方案
当无法改结构、不能建临时表、又必须用IN时，硬拆是唯一办法——但要控制单批大小和总批数。
- 单批
IN元素建议≤500个，MySQL对长IN列表解析开销明显上升 - 用
UNION ALL拼接，别用UNION：后者会去重，额外排序+临时表 - 应用层需自己做结果合并，注意字段顺序、NULL处理、重复ID（如有）
- 极端情况（如10万ID），拆50–100批，配合连接池复用，比单条30秒超时强得多
真正容易被忽略的是：无论选哪种优化，EXPLAIN必须跑一遍，确认type是ref或range，rows接近实际匹配数，而不是动辄百万级扫描。没看执行计划就改SQL，等于蒙眼调优。
