IN子句本身不慢，慢因滥用：超200值触发优化器降级致全表扫描；子查询未索引、类型不匹配或含NULL均致索引失效；应控列表在100–200内、改用带主键临时表JOIN、EXISTS替代IN子查询，并确保字段类型一致、关联列有索引。
IN子句本身不慢，慢是因为你让它在不该用的地方硬扛大数据量——比如列表超200项、子查询没索引、字段类型不匹配，或者根本没走索引。
IN列表超过200个值就别硬拼了
MySQL优化器在eq_range_index_dive_limit默认值（200）触发后，会放弃对索引的精细统计，转而粗略估算成本，大概率跳过索引直接全表扫描。这不是bug，是它“算不过来”时的理性退让。
- 单次
IN建议控制在100–200项以内；超出就拆批，比如每150个ID发一次查询 - 若ID来自应用层集合，优先走
CREATE TEMPORARY TABLE tmp_ids (id BIGINT UNSIGNED PRIMARY KEY)，再JOIN——临时表必须带PRIMARY KEY，否则JOIN极易退化为type: ALL -
INSERT INTO tmp_ids VALUES (1),(2),...,(150)批量插入，别单条循环；但单批别超1000行，防max_allowed_packet截断 - 用完记得
DROP TEMPORARY TABLE tmp_ids，连接池复用时残留表会报Table 'tmp_ids' already exists
IN子查询必须改写，不能只加索引
写成WHERE col IN (SELECT col FROM t2 WHERE ...)，哪怕t2.col有索引，MySQL 5.7+也常物化整个子结果集——几十万行一塞，tmp_table_size超限就落盘，IO暴涨。
- 改用
EXISTS：把WHERE col IN (SELECT col FROM t2 WHERE cond)换成WHERE EXISTS (SELECT 1 FROM t2 WHERE t2.col = t1.col AND cond)，语义等价且“找到一个就停” - 别写
SELECT *进EXISTS子查询，字段越多，优化器越难判断；写SELECT 1最安全 -
NOT IN遇到子查询返回NULL，整行恒为FALSE，逻辑错+索引失效；必须改NOT EXISTS，不能用LEFT JOIN ... IS NULL混搭 - 确保关联条件中
t2.col = t1.col的t2.col有索引，否则EXISTS照样扫全表
字段类型不一致会让索引彻底失效
看着SQL能跑通，EXPLAIN里key却是NULL？八成是隐式转换——比如user_id是BIGINT，你却写了WHERE user_id IN ('1', '2')，MySQL得把每个字符串转成数字再比，索引无法下推。
- 整数类字段，
IN里的字面量别加引号：IN (1, 2, 3)✅，IN ('1', '2')❌ - UUID类字段是
CHAR(36)，必须带引号：IN ('a1b2...', 'c3d4...')✅，不加引号会转成0 - 用
SHOW CREATE TABLE确认字段定义，避免VARCHAR和INT混用；外部传入的ID先在应用层校验并强转类型 - 查
EXPLAIN输出，重点看type是否为ALL或index、key是否非空、Extra是否含Using temporary
真正卡住性能的，往往不是IN语法本身，而是物化临时表、隐式类型转换、NULL值逻辑陷阱这些看不见的坑——改写前先EXPLAIN，改写后对比Created_tmp_disk_tables指标，比猜更可靠。
