mysql优化器对in列表长度敏感，超500项易退化执行计划：少于100项走range扫描，100–1000项rows_examined上升，超1000项常降级为index或all扫描；长in还触发max_allowed_packet限制、解析开销增大、隐式转换使索引失效；推荐用临时表+join替代，但需建索引并注意连接生命周期。
MySQL优化器对IN列表长度敏感，超过500项就可能退化执行计划
MySQL不是“不支持大IN”，而是优化器在评估成本时会随着IN列表增长逐步放弃索引。当列表元素少于100个，通常走range扫描；100–1000之间，rows_examined开始明显上升；超过1000后，EXPLAIN里常出现type: index或ALL，说明已降级为索引全扫甚至全表扫描。
这不是语法错误，而是优化器基于统计信息做的“成本误判”——它把长IN等价展开成一堆OR条件，再估算匹配行数，结果常常低估实际开销。用EXPLAIN FORMAT=JSON看attached_condition字段，能发现谓词复杂度陡增。
IN子句过长会触发max_allowed_packet和解析瓶颈
客户端发过去的SQL本身就是一条超长字符串。若IN含5000个整数ID，光括号内文本就可能超几MB，直接撞上max_allowed_packet默认值（通常4MB）。一旦超限，MySQL返回Packets for query is too large错误，查询根本不会进优化器。
- 即使没超限，SQL解析阶段也要做词法/语法分析、参数绑定、生成执行树，这部分CPU开销随
IN长度线性增长 - 长SQL还导致查询缓存失效（MySQL 8.0已移除，但5.7及以前仍受影响）
- 连接池中线程被长时间占用，加剧并发阻塞
字符串IN或隐式转换会让索引彻底失效
如果WHERE id IN ('1','2','3')中id是INT类型，MySQL必须对每个字符串做类型转换，导致无法使用id上的索引。这种写法在开发环境可能看不出问题，一到生产环境数据量上来，rows_examined立刻飙升。
更隐蔽的是字符集不一致：比如表字段用utf8mb4，而传入的IN值按latin1编码发送，也会触发隐式转换。用SHOW WARNINGS能捕获这类Cannot use range access on index提示。
临时表+JOIN比大IN更可控，但要注意生命周期和索引
用CREATE TEMPORARY TABLE把ID存进去再JOIN，本质是把“一次性解析大SQL”变成“两次小操作”：一次插入、一次关联。优势明显，但容易忽略两个细节：
- 临时表默认无索引，
INSERT后必须显式加PRIMARY KEY或INDEX，否则JOIN仍是全表扫描 -
TEMPORARY TABLE只在当前连接有效，应用层需确保整个事务中连接不释放，否则表消失导致Table 'temp_ids' doesn't exist - 若ID重复，
INSERT IGNORE或ON DUPLICATE KEY UPDATE比单纯INSERT更安全
真正难处理的不是技术选型，而是业务逻辑是否允许拆分——比如订单状态批量更新要求强一致性，就不能简单分批；而用户行为分析类查询，分批+合并结果反而更稳。
