IN子查询没走索引主因是优化器无法使用索引，常见于子查询结果集过大、字段类型不匹配、隐式转换或子查询自身全表扫描（EXPLAIN显示type=ALL），需单独验证子查询执行计划并确保类型严格一致、避免函数操作、改用JOIN替代依赖型子查询。
IN 子查询没走索引，不是语法写错了，而是优化器根本没机会用上索引——常见情况是右边子查询结果集太大、字段类型不一致，或者外层条件压根没触发索引下推。
子查询单独执行时 EXPLAIN 显示 type=ALL
这说明子查询本身就在全表扫描，不是“外层拖累”，而是内层已经崩了。比如：SELECT id FROM users WHERE status = 'active' 如果 status 没索引，或用了 WHERE UPPER(status) = 'ACTIVE' 这种函数，EXPLAIN 就会标 type=ALL。
实操建议：
- 先把子查询拎出来单独 EXPLAIN，确认它是否能走索引
- 检查 status 字段类型是不是和查询值严格一致（比如 VARCHAR 对 'active'，不能是 TEXT 或带空格的 CHAR）
- 避免在子查询 WHERE 里对索引列做任何计算或函数调用
IN 左右两边字段类型不匹配导致索引失效
这是最隐蔽也最常踩的坑：左边是 BIGINT，右边子查询返回的是 VARCHAR，MySQL 会隐式转换，结果就是两边都放弃索引。现象是 EXPLAIN 里 key 为 NULL，possible_keys 却有值。
实操建议：
- 用 SELECT COLUMN_NAME, DATA_TYPE FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME = 'orders' AND COLUMN_NAME = 'user_id' 查左边字段类型
- 同样查子查询源头表（如 users.id）的类型，必须完全一致
- 如果子查询来自视图或复杂表达式，加 CAST(... AS SIGNED) 或 CONVERT(..., UNSIGNED) 强制转类型
EXPLAIN 出现 DEPENDENT SUBQUERY
这意味着子查询依赖外层字段，数据库不得不为外层每一行重新执行一次。比如：SELECT * FROM orders WHERE user_id IN (SELECT id FROM users WHERE users.id = orders.user_id AND status = 'active')，哪怕 users.id 有索引，只要 status 没索引或条件写法不当，就会退化成嵌套循环。
实操建议：
- 把这种写法直接换成 JOIN：SELECT o.* FROM orders o JOIN users u ON o.user_id = u.id WHERE u.status = 'active'
- 确保 JOIN 条件字段（u.id 和 o.user_id）都有索引，且类型一致
- 如果驱动表选错（比如 orders 是大表却当了左表），加 STRAIGHT_JOIN 强制顺序
LIMIT 在子查询里不生效，仍扫全表
MySQL 5.7 及更早版本中，SELECT * FROM orders WHERE user_id IN (SELECT id FROM users ORDER BY last_login DESC LIMIT 10) 看似只取 10 行，但优化器可能先生成全部 users 结果再过滤，尤其当 users 没索引时。
实操建议：
- 把带 LIMIT 的子查询提前物化：先 CREATE TEMPORARY TABLE tmp_users SELECT id FROM users ORDER BY last_login DESC LIMIT 10，再 IN 这张临时表
- 或改用 JOIN + LIMIT 套子查询外层：SELECT o.* FROM orders o JOIN (SELECT id FROM users ORDER BY last_login DESC LIMIT 10) u ON o.user_id = u.id
- MySQL 8.0+ 可用 WITH CTE 提前固化结果，但依然要确保 CTE 内部能走索引
真正卡住性能的，往往不是子查询语法本身，而是字段类型错位、隐式转换、或优化器被误导后放弃索引下推——这些细节在 EXPLAIN 里都藏得明明白白，但没人看。
