IN子句超200值时执行计划崩坏，因MySQL默认eq_range_index_dive_limit=200，触发估算降级致索引弃用；应改用临时表JOIN或分批查询（≤200/批）来规避。
IN 子句传几百上千个值时，查询变慢甚至结果错乱，不是你写法有问题，而是数据库优化器主动“放弃精确评估”了——它不再逐个探测索引，转而靠统计信息瞎猜。
MySQL中IN超过200个值为什么执行计划突然崩坏？
MySQL 5.7/8.0 默认 eq_range_index_dive_limit = 200。一旦 IN 列表长度超这个数，优化器就跳过 index dive（索引深度探测），改用粗略估算，常导致选错索引、全表扫描。
- 查当前阈值：
SHOW VARIABLES LIKE 'eq_range_index_dive_limit'; - 确认是否已降级：
EXPLAIN FORMAT=JSON看"range_analysis"段里有没有"index_dives_for_eq_ranges": false - 别指望调高
eq_range_index_dive_limit——它只是让优化器更“努力”，但不解决解析开销和max_allowed_packet超限问题
用临时表 + JOIN 替代大列表IN的实操要点
把 ID 列表从 SQL 字符串里摘出来，存进临时表再关联，是目前最稳的通用解法。
- 建表（推荐
Memory引擎 + 主键）：CREATE TEMPORARY TABLE tmp_ids (id BIGINT NOT NULL PRIMARY KEY) ENGINE=Memory; - 批量插入（避免单条
INSERT）：INSERT INTO tmp_ids VALUES (1),(2),(3),...,(1000); - 关联查询（必须用
JOIN，不是IN (SELECT ...)）：SELECT t.* FROM target_table t JOIN tmp_ids i ON t.id = i.id; - 注意：用
IN (SELECT id FROM tmp_ids)又退回子查询模式，可能物化失败或退化成嵌套循环
无法建临时表时，分批查询怎么避坑？
只读库、无 DDL 权限、或 ID 来自不可信前端输入时，分批是唯一安全选择。
- 单批控制在
500～1000个值以内，避开eq_range_index_dive_limit和max_allowed_packet双重风险 - 应用层循环发多个
IN查询，结果合并（Java 用Stream.concat，Python 用itertools.chain） - 别用
UNION ALL在 SQL 层拼接——语句过长照样触发Packets larger than max_allowed_packet are not allowed - 含
ORDER BY和LIMIT的场景必须在外层统一排序分页，否则各批次结果交叉，逻辑错乱
IN子查询 vs EXISTS：什么情况下必须换？
当右边是子查询且要关联外层字段时，IN 语法直接报错，EXISTS 是唯一合法写法。
-
WHERE id IN (SELECT user_id FROM logs WHERE logs.time > orders.created_at)→ 语法错误，必须改写为EXISTS -
IN子查询返回NULL会导致整行被排除；EXISTS不受NULL影响 - MySQL 5.7 以前，
IN子查询常退化为嵌套循环；EXISTS配合合适索引通常快一个数量级 - 大数据量子查询场景下，优先测
EXISTS执行计划，别默认沿用IN
真正容易被忽略的点是：空列表、NULL 值、类型混用这三类问题不会报错，但结果完全不对——比如传空数组给 IN ()，MySQL 直接报语法错，PostgreSQL 却静默返回空集；IN (1, '2') 这种混合类型在多数引擎里会触发隐式转换，索引失效。这些必须在应用层提前校验，不能依赖数据库兜底。
