子查询WHERE条件未走覆盖索引，主因是优化器将子查询物化为无索引临时表，或NULL值、联合索引最左前缀不匹配导致；应改写为JOIN、排除NULL、确保索引列参与查询条件，并通过EXPLAIN验证执行计划。
子查询的 WHERE 条件没走覆盖索引，通常不是因为子查询本身“不支持”，而是执行计划里那个子查询被物化（materialized）或转成了临时表，导致原本能走的索引失效了——本质是优化器放弃了索引访问路径。
子查询被物化后索引就断了
MySQL 5.7+ 对非相关子查询（比如 SELECT * FROM t1 WHERE id IN (SELECT id FROM t2 WHERE status=1)）常会先执行内层，把结果写进隐式临时表。这个临时表默认无索引，外层再查它时自然没法用 t2.status 上的索引。
- 用
EXPLAIN看执行计划，如果type是ALL或index，且Extra出现Using temporary，基本就是这问题 - 把子查询改写成
JOIN：例如SELECT t1.* FROM t1 JOIN t2 ON t1.id = t2.id WHERE t2.status = 1，这样优化器更容易下推条件、复用t2.status的索引 - 如果必须用子查询，尝试加
FORCE INDEX到内层表（但仅当内层是单表且条件明确时才有效）
IN 子查询中存在 NULL 值导致索引失效
当内层子查询返回结果含 NULL，比如 SELECT id FROM t2 WHERE status = 1 OR status IS NULL，MySQL 为保证语义正确（IN (..., NULL) 恒为 UNKNOWN），可能放弃使用索引而走全表扫描。
- 检查子查询是否可能返回
NULL：SELECT COUNT(*) FROM t2 WHERE status = 1 AND id IS NULL - 显式排除
NULL：SELECT id FROM t2 WHERE status = 1 AND id IS NOT NULL - 用
EXISTS替代IN（尤其在外层大、内层小时），EXISTS不受NULL影响，也更容易命中索引
子查询列未包含在联合索引最左前缀中
即使你建了 INDEX(status, id)，但如果子查询写的是 SELECT id FROM t2 WHERE id = 123，这个条件根本没用上 status，优化器发现单独查 id 无法利用该联合索引，就会跳过它。
- 确认子查询
WHERE中实际使用的列，是否构成索引的最左前缀 - 必要时建单列索引：
ALTER TABLE t2 ADD INDEX idx_id (id) - 若同时要查
status和id，且经常组合过滤，优先建INDEX(status, id)；若只按id查，单列索引更轻量
真正卡住性能的，往往不是“子查询不能用索引”，而是你没看见优化器悄悄把它重写了——盯紧 EXPLAIN 的 select_type 和 Extra 字段，比背规则有用得多。
