in子查询没走索引主因是字段类型或排序规则不一致导致隐式转换，使索引失效；典型现象为explain显示type=all或key=null，且常伴dependent subquery，需单独验证子查询执行计划并严格对齐类型、collation、驱动表与索引设计。
子查询里 IN 没走索引，外层每行都触发全表扫描
典型现象是 EXPLAIN 显示外层 type=ALL 或 key=NULL，而你明明给 orders.user_id 加了索引。根本原因不是语法错，而是子查询返回的字段类型或排序规则（COLLATION）和外层字段不一致，MySQL 被迫对每一行做隐式转换，索引直接失效。
实操建议：
- 先单独执行子查询并
EXPLAIN：比如EXPLAIN SELECT id FROM users WHERE status = 'active'，确认它本身能走users.status索引 - 再对外层 + 子查询整体
EXPLAIN，重点看是否出现DEPENDENT SUBQUERY—— 这说明外层每扫一行，子查询就被重执行一次 - 用
SHOW FULL COLUMNS FROM users LIKE 'id'和DESCRIBE (SELECT id FROM users) AS tmp对比字段类型与Collation，二者必须完全一致 - 避免在子查询中用
CONCAT()、IFNULL()包裹主键字段；若必须处理空值，改用WHERE id IS NOT NULL过滤
NOT IN 遇到 NULL 时静默变慢查
NOT IN (SELECT user_id FROM events) 看似简洁，但只要子查询结果里含任意一个 NULL，整个条件就恒为 UNKNOWN，MySQL 无法下推索引，退化成嵌套循环+全表扫描。测试中 1000 万行 events 表，NOT IN 耗时 2 分钟，NOT EXISTS 只要 0.01 秒。
实操建议：
- 永远用
NOT EXISTS替代NOT IN做存在性校验，写法更稳：WHERE NOT EXISTS (SELECT 1 FROM events b WHERE b.user_id = a.id AND b.type = 7) - 子查询中必须带关联条件（如
b.user_id = a.id），否则变成非相关子查询，仍可能全表扫 - 确保
events.user_id有索引，且类型与users.id严格一致（比如都是BIGINT UNSIGNED） - 如果业务真需要
NOT IN，务必加AND user_id IS NOT NULL过滤掉空值，但这只是补救，不如直接换NOT EXISTS
字符集或排序规则（COLLATION）不一致导致索引失效
字段定义是 utf8mb4_0900_as_cs，但连接层 @@collation_connection 是 utf8mb4_unicode_ci，或者子查询返回列的 Collation 是 utf8mb4_general_ci，三者只要有一对不匹配，MySQL 就拒绝用索引，宁可全表扫描。
实操建议：
- 查三层真实值：
SHOW FULL COLUMNS FROM t1 LIKE 'name'、SHOW FULL COLUMNS FROM (SELECT name FROM t2) AS tmp、SELECT @@collation_connection - 统一修改字段
COLLATE时，必须同时指定CHARACTER SET和COLLATE，例如：ALTER TABLE t2 MODIFY name VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_as_cs - 应用连接字符串里显式指定
collation=utf8mb4_0900_as_cs，避免依赖服务端默认值 - 别在 SQL 里硬写
COLLATE或CONVERT临时修复，这会让执行计划不可控，且 ORM 生成的语句不会自动继承
用 JOIN 替代子查询时驱动表选错
把 IN 改成 JOIN 不一定快。如果小表（如 users 只有几千行）被当成了被驱动表，大表（如 orders 百万行）反而成了驱动表，就会触发 Block Nested-Loop Join，性能比原 IN 更差。
实操建议：
- 让结果集小的表做驱动表：例如活跃用户数少，就写
SELECT o.* FROM users u JOIN orders o ON o.user_id = u.id WHERE u.status = 'active' - 用
STRAIGHT_JOIN强制顺序（仅当优化器选错时）：SELECT STRAIGHT_JOIN o.* FROM users u JOIN orders o ON ... - 被驱动表（如
orders）上建联合索引，按驱动表过滤字段顺序来设计，例如(user_id, status, created_at)，而非只建单列user_id - 验证执行计划：理想是驱动表
type=ref，被驱动表type=eq_ref或ref；若出现type=ALL或Using join buffer，说明驱动表或索引没配对
复杂点在于：类型、排序规则、连接层配置、驱动表选择，这四者得同时对齐。漏掉任何一个，索引就还在那儿，但就是不用。
