mysql中in查询超200值性能骤降，因优化器改用统计估算致执行计划劣化；max_allowed_packet限制sql长度；隐式类型转换使索引失效；临时表+join是较优解，但需注意索引与连接生命周期。
MySQL 中 IN 查询一旦超过几百个值，性能就可能断崖式下跌——这不是 bug，而是优化器在“权衡成本”时主动放弃精确评估的结果。
为什么 eq_range_index_dive_limit 是关键阈值
MySQL 用两个不同策略估算 IN 的执行成本：当列表长度小于 eq_range_index_dive_limit（5.7/8.0 默认都是 200），它会真正去索引树里逐个探查（index dive），得到较准的行数预估；一旦 ≥ 这个值，就改用统计信息粗略估算（index statistics），极易误判为“全扫比走索引更便宜”。
- 你看到
EXPLAIN里type: range突然变成type: index或ALL，基本就是跨过了这个阈值 - 哪怕你只多加一个值，执行计划也可能从毫秒级跳到分钟级
-
SHOW VARIABLES LIKE 'eq_range_index_dive_limit'可查当前值，但不建议盲目调高——它解决的是估算精度，不是根本瓶颈
max_allowed_packet 会在你没注意时直接拦停查询
客户端发过去的是一整条 SQL 字符串。若 IN (1,2,3,...,10000) 展开后文本超限（默认 4MB），MySQL 根本不进优化器，直接报错：Packets for query is too large。
- 实际中，5000 个整型 ID 就可能逼近甚至突破该限制
- 即使没报错，超长 SQL 也会显著增加 parser 阶段 CPU 开销，且无法命中查询缓存（5.7 及以前）
-
SET SESSION max_allowed_packet = 64*1024*1024可临时调大，但治标不治本——连接池线程仍会被长时间独占
隐式类型转换让索引彻底失效
最隐蔽也最致命的问题：字段是 INT，但传入的是字符串 IN ('1','2','3')。MySQL 必须对每个值做 CAST，导致无法使用 id 上的索引。
- 这种写法在测试库数据少时完全看不出问题，上线后
rows_examined瞬间暴涨几十倍 - 字符集不一致（如表用
utf8mb4，参数按latin1发送）也会触发同类型转换 -
SHOW WARNINGS能捕获Cannot use range access on index提示，务必养成习惯
临时表 + JOIN 不是万能解，但最容易落地
把大批量 ID 先写进 TEMPORARY TABLE 再关联，本质是把“一次巨长 SQL”拆成“一次小插入 + 一次标准 JOIN”，可控性高得多。
- 必须显式建索引：
CREATE TEMPORARY TABLE tmp_ids (id INT PRIMARY KEY)，否则JOIN仍是全表扫描 - 临时表只在当前连接生命周期内存在，应用层要确保事务中连接不被连接池回收，否则出现
Table 'tmp_ids' doesn't exist - Memory 引擎 + HASH 索引适合等值匹配，但不支持 BLOB/TEXT；若 ID 含 UUID，优先选
CHAR(36) PRIMARY KEY而非 HASH
真正难处理的从来不是“怎么写”，而是“谁来决定拆多少批、什么时候建临时表、ID 重复要不要去重”。这些边界细节，往往比语法本身更消耗线上稳定性。
