in子句值过多会触发硬解析失败、索引失效或超时，主因是eq_range_index_dive_limit限制、prepare/execute支持差及优化器弃用索引；应改用带主键的临时表join，并确保类型、字符集、排序规则一致。
IN子句里塞几千个值，不是“有点慢”，而是大概率触发硬解析失败、索引失效、甚至直接超时——这不是配置问题，是 MySQL 内部机制决定的。
为什么 IN 参数一多就崩：不只是“SQL太长”
很多人以为只是字符串拼得太长，其实核心卡点在三处：
-
eq_range_index_dive_limit默认值是 200，超过这个数，MySQL 就放弃扫描索引树（index dive），改用粗略的索引统计估算成本 → 执行计划极易出错，比如该走ref却选了ALL - PREPARE/EXECUTE 对长参数列表支持极差：客户端驱动可能截断、报
Packets too large，服务端解析含上千字面量的 SQL，语法树构建耗时剧增 - IN 值数量 > 5000 时，优化器常主动弃用索引，转为全表扫描；即使字段有索引，
EXPLAIN中key字段也会变成NULL
用 JOIN 替代 IN：必须带主键，否则白忙
光把 WHERE id IN (1,2,3) 改成 JOIN 不解决问题。关键动作是让临时数据可索引、可驱动：
- 创建临时表时必须加主键：
CREATE TEMPORARY TABLE tmp_ids (id BIGINT UNSIGNED PRIMARY KEY)—— 没主键 = 没索引 = JOIN 退化为嵌套循环 - 批量插入别单条执行：
INSERT INTO tmp_ids VALUES (1),(2),(3),...,(1000)，每批 ≤ 1000 行，比逐条快 10 倍以上 - JOIN 写法要控制驱动顺序：
SELECT t.* FROM target_table t INNER JOIN tmp_ids i ON t.id = i.id，确保tmp_ids是驱动表 - 目标表字段没索引？
JOIN也救不了你：ALTER TABLE target_table ADD INDEX idx_id (id)得先补上
临时表引擎选错，性能反而更差
ENGINE=MEMORY 看似快，但限制致命：
- 受
max_heap_table_size控制，默认仅 16MB → 插 10 万个BIGINT就爆内存 - 不支持
TEXT/BLOB，字符字段类型稍有不一致（比如VARCHARvsCHAR）就会隐式转换，导致索引失效 - 超过 5 万 ID 或含字符串字段，直接切
ENGINE=InnoDB：CREATE TEMPORARY TABLE tmp_ids (id VARCHAR(32), PRIMARY KEY(id)) ENGINE=InnoDB - 别忘了显式
DROP TEMPORARY TABLE tmp_ids—— 虽然会话结束自动删，但连接池复用时可能残留旧数据
LEFT JOIN 后没结果？大概率掉进这几个坑
建好表、插完数据、写完 JOIN 却查不到任何行，不是逻辑错，而是这些细节被忽略：
- 临时表里混了
NULL：ON t.id = i.id中任意一边为NULL，整个条件恒为FALSE - 类型不一致：主表
id是BIGINT，临时表建成了INT，某些 MySQL 版本会静默截断或拒绝匹配 - 字符集/排序规则不匹配：主表字段用
utf8mb4_0900_as_cs，临时表却用默认utf8mb4_general_ci→ 隐式转换，索引失效 - 大小写敏感字段（
_cscollation）插入小写值，但主表存的是大写 → 白匹配
真正卡住性能的，从来不是 IN 这个语法本身，而是改写后索引是否真能命中、类型是否干净、临时表是否真被当“表”用——这些地方一松懈，优化就等于没做。
