子查询导致WHERE无法用索引，主因是MySQL 5.7及之前对非物化子查询采用先执行后匹配策略，使外层表无法索引定位；改用JOIN、EXISTS或强制物化可缓解。
子查询为什么让 WHERE 条件用不上索引
不是所有子查询都必然失效，但绝大多数 MySQL 5.7 及之前版本中，IN 或 = 后跟非物化子查询时，优化器会放弃使用外层表的索引。典型表现是执行计划里出现 type: ALL 或 Extra: Using where; Using join buffer。
根本原因是：MySQL 在早期版本中对子查询的处理策略偏保守——它先执行子查询（可能全表扫），再拿结果去匹配外层，导致外层无法利用索引做快速定位；即使子查询本身有索引，也救不了外层。
- 子查询返回多行且未加
LIMIT 1，又没被优化器自动物化，就大概率触发该问题 -
EXISTS子查询通常比IN更友好，因为它是“半连接”语义，常能走索引 - MySQL 8.0+ 引入了更激进的子查询物化和 LATERAL 支持，但默认仍不保证生效，需配合
/*+ MATERIALIZE */提示
把 IN (SELECT ...) 改成 JOIN 的实操要点
这是最常用、兼容性最好、效果最稳的转化方式。核心思路是：把子查询结果“展开”为临时中间集，再与主表关联。
注意不是简单套 JOIN 就完事——字段去重、NULL 处理、重复行逻辑必须和原语义一致。
- 原语句是
WHERE id IN (SELECT user_id FROM logs WHERE status = 1)，对应改写为INNER JOIN logs ON t.id = logs.user_id AND logs.status = 1 - 如果原
IN允许NULL（比如子查询可能返回 NULL），而JOIN会自动过滤掉 NULL 匹配，此时得补OR t.id IS NULL或改用LEFT JOIN + IS NOT NULL - 子查询含
GROUP BY或聚合，直接JOIN会放大主表行数，应先用派生表（FROM (SELECT DISTINCT ...) AS tmp）压平
EXISTS 替代 IN 的适用边界和陷阱
EXISTS 一般能保留外层索引，因为它只关心“是否存在匹配”，不取子查询实际值，优化器更容易下推条件。
但它不是万能替代：语义不同、NULL 行为不同、部分场景反而更慢。
- 原
WHERE x IN (SELECT y FROM t2 WHERE ...)可改为WHERE EXISTS (SELECT 1 FROM t2 WHERE t2.y = t1.x AND ...) - 若子查询中引用了外层字段（相关子查询），
EXISTS性能未必好——每次外层行都要执行一次子查询，索引虽在，但 I/O 次数可能翻倍 -
NOT EXISTS和NOT IN行为差异极大：NOT IN遇到子查询任意一行是NULL，整个结果变空；NOT EXISTS不受 NULL 影响
MySQL 8.0+ 下启用子查询物化的关键配置和提示
新版 MySQL 默认仍可能跳过物化，尤其当子查询看起来“太小”或“太复杂”时。不能只靠版本升级，得主动干预。
物化生效的前提是子查询结果能缓存在内存/磁盘临时表中，并支持索引查找——这要求子查询本身不含不可物化结构（如依赖外层变量的函数调用）。
- 强制物化：在子查询前加
/*+ MATERIALIZE */注释，例如SELECT * FROM t1 WHERE id IN (/*+ MATERIALIZE */ SELECT user_id FROM logs WHERE ...) - 关闭半连接优化（有时反而是解药）：
SET optimizer_switch='semijoin=off';，避免优化器强行转成低效的半连接算法 - 检查
tmp_table_size和max_heap_table_size，物化结果过大时会落盘，影响速度；但太小又会导致频繁切换引擎
真正难的不是换写法，而是判断哪条路径在你的数据分布、索引结构、MySQL 版本下实际更快——EXPLAIN FORMAT=TREE 和 SHOW STATUS LIKE 'Handler_%' 比任何经验都管用。
