IN查询走不了索引的三个硬性原因是值太多（超300–500触发优化器降级）、值太散（索引页跳跃导致成本估算认为全扫更优）、字段被隐式转换（如BIGINT列传字符串或函数包裹）；必须同时满足单列索引存在、无计算/转换、值数量适中、类型严格匹配四条件才能稳定命中索引。
IN查询走不了索引的三个硬性原因
IN条件写了索引却没走，不是MySQL抽风，而是优化器明确放弃了range访问。常见现象是EXPLAIN里type显示ALL或index，possible_keys为空或rows远超实际匹配数。根本卡点就三个：值太多、值太散、字段被隐式转换。
-
值太多：MySQL 5.7 默认在 IN 列表超过 300–500 个值时，可能直接退化为全表扫描；8.0+ 虽更激进，但依然受range_optimizer_max_mem_size限制（默认 8MB） -
值太散：比如status IN (1, 99, 200, 999...)，索引页跳跃严重，优化器估算成本后认为不如扫一遍 -
字段被隐式转换：user_id是BIGINT，但传了'1','2'字符串，或用了UPPER(name)包裹，索引立刻失效
让IN稳定走索引的四个必要条件
必须同时满足，缺一不可。哪怕建了索引，只要其中一条不成立，IN 就大概率绕开它。
-
单列索引存在：复合索引只对最左连续部分生效，INDEX(a,b,c)下WHERE a = 1 AND b IN (2,3)可用，但WHERE a IN (1,2) AND c = 3只能用到a -
字段无计算/转换：禁止在IN左侧加函数、类型转换、表达式，如CAST(id AS CHAR)、DATE(created_at) -
IN值数量适中：生产环境建议控制在 200–500 以内；若动态生成，需预估上限并做截断或分批 -
类型严格匹配：整型字段必须传整型，字符串字段注意字符集和排序规则一致，避免utf8mb4_0900_as_csvsutf8mb4_general_ci冲突
IN列表过大时临时表+JOIN的真实写法
这不是“替代方案”，而是唯一能绕过解析瓶颈、稳定走索引的落地方式。关键细节决定成败，错一步性能反而更差。
- 临时表必须带
PRIMARY KEY或UNIQUE约束，否则JOIN会退化为嵌套循环+全表扫 -
INSERT要用多值批量插入，每次最多 1000 行；拆成单行插入或超大单条语句，IO 和解析开销反而更高 - 临时表字段类型要和主表完全一致，比如主表
user_id BIGINT UNSIGNED，临时表也得是BIGINT UNSIGNED - 执行顺序不能错：先
CREATE TEMPORARY TABLE，再INSERT，最后JOIN；中间任何一步失败，临时表自动销毁，无法复用
示例：
CREATE TEMPORARY TABLE tmp_user_ids (id BIGINT UNSIGNED PRIMARY KEY); INSERT INTO tmp_user_ids VALUES (1001),(1002),(1003),...,(2000); SELECT u.* FROM users u JOIN tmp_user_ids t ON u.id = t.id;
为什么EXISTS有时比IN快，但不是万能解
EXISTS 在“是否存在”场景下有短路优势，但它不解决索引命中问题——如果子查询里的字段没索引，EXISTS 一样慢。
- 适用场景：外层表小、内层表大，且只需判断存在性，例如
SELECT * FROM users u WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id AND o.status = 'paid') - 不适用场景：需要返回内层表字段，或内层查询本身没索引（比如
orders(user_id)缺失），此时 EXISTS 和 IN 都会扫全表 - 别盲目替换：把
IN改成EXISTS前，先用EXPLAIN看子查询是否走了索引；没索引就先加，而不是换语法
真正容易被忽略的点是：索引是否覆盖了所有参与比较的字段，以及临时表的主键是否与关联字段类型、符号完全一致。这两处出错，其他所有优化都白搭。
