EXPLAIN可直接验证子查询是否走索引，关键看type和key列；IN/NOT IN易因NULL或隐式转换导致全表扫描，应改用JOIN或排除NULL；相关子查询引发N+1问题，宜转为LEFT JOIN+GROUP BY。
EXPLAIN 看清执行计划里到底走了没
别猜，直接 EXPLAIN。子查询是否走索引，不是看“有没有建”，而是看执行计划里 type 和 key 列的实际值。常见误判是：以为 SELECT * FROM t1 WHERE id IN (SELECT id FROM t2) 会自动复用 t2.id 上的索引，但 EXPLAIN 很可能显示 type: ALL、key: NULL —— 这说明子查询被当成了驱动表全扫。
重点看三处：
- 外层主查询的
key是否非空，type是否为ref/range（而非ALL） - 子查询所在行（如
select_type: SUBQUERY或DEPENDENT SUBQUERY）的key是否命中索引 - 若出现
Using temporary或Using filesort，基本可断定中间结果未受控，索引已失效
IN / NOT IN 子查询不走索引的典型陷阱
IN 和 NOT IN 是重灾区。MySQL 对 NOT IN 的处理尤其保守：只要子查询结果含 NULL，整个条件就恒为 FALSE，优化器干脆放弃索引下推，改走 NESTED-LOOP ANTI JOIN 并全表扫描被驱动表。
排查和修复要点：
- 先确认子查询是否返回
NULL：SELECT COUNT(*) FROM t2 WHERE id IS NULL - 显式排除
NULL：WHERE id IN (SELECT id FROM t2 WHERE id IS NOT NULL) - 把
NOT IN改成LEFT JOIN ... IS NULL，能稳定利用两边索引 -
DELETE语句中的IN子查询比SELECT更容易跳过索引——因为优化器对写操作更保守，务必单独EXPLAIN验证
相关子查询导致 N+1 扫描的根本原因
像 SELECT id, (SELECT COUNT(*) FROM logs l WHERE l.order_id = o.id) FROM orders o 这种写法，表面简洁，实则每行 o.id 都触发一次独立子查询。即使 logs.order_id 有索引，也只在单次子查询中生效；而整体执行代价是 orders 行数 × 单次 logs 索引查找成本。
这不是“索引没走”，而是“索引被反复走但总耗时爆炸”。解决方向很明确：
- 优先转成
LEFT JOIN + GROUP BY，让 MySQL 一次性完成关联与聚合 - 若必须保留子查询逻辑，确保子查询是
NON-CORRELATED（即不依赖外层字段），这样可物化一次复用 - 检查子查询是否真的需要实时计算——部分场景可用物化视图或冗余统计字段替代
隐式转换和函数让索引彻底失效
子查询里对索引字段套函数、做类型转换，会直接切断索引使用链。比如子查询写成 SELECT id FROM t2 WHERE DATE(create_time) = '2024-01-01'，哪怕 create_time 有索引，也会退化为全表扫描。
这类问题常藏得深，因为外层看不出异常。排查时盯紧子查询的 WHERE 条件：
- 禁止在索引列上用
YEAR()、DATE()、UPPER()等函数 - 字符串字段比较时，确认两边类型一致：
WHERE name = 'abc'vsWHERE name = 123（后者触发隐式转换） - 模糊匹配慎用后缀：
LIKE '%abc'无法走索引，LIKE 'abc%'才可以 - 时间范围查询用闭区间：
create_time >= '2024-01-01' AND create_time ，别用 <code>DATE(create_time) = ...
子查询索引失效最麻烦的地方在于：它往往不是单一原因，而是执行计划层级、数据分布、NULL 值、类型转换、优化器版本多个因素叠加的结果。每次遇到，都得从 EXPLAIN 出发，逐层拆解子查询的独立执行路径，而不是只盯着外层 SQL 写法。
