in子查询性能差源于mysql强制物化整个子结果集，优化首选exists或join替代，避免临时表和全表扫描。
MySQL 5.7 中子查询让外层 WHERE 条件无法走索引，不是写法错了，而是优化器策略限制——它默认不物化子查询，导致外层表被迫全表扫描。解决方向很明确：绕过子查询执行模型，把逻辑转成优化器能下推条件、能利用索引的结构。
IN 子查询改写为 JOIN 时必须处理的三个细节
直接把 WHERE id IN (SELECT user_id FROM logs WHERE status = 1) 换成 INNER JOIN 不够，语义可能已变：
- 原
IN允许子查询返回NULL，而JOIN会自动过滤掉NULL匹配行；若业务需保留主表中id IS NULL的记录，得补上OR t.id IS NULL或改用LEFT JOIN ... IS NOT NULL - 子查询含
GROUP BY或聚合（如COUNT），直接JOIN会导致主表行被放大；应先用派生表压平：FROM t INNER JOIN (SELECT DISTINCT user_id FROM logs WHERE status = 1) AS tmp ON t.id = tmp.user_id - 子查询结果有重复
user_id，INNER JOIN会引发主表行重复；加DISTINCT或用EXISTS更安全
EXISTS 替代 IN 的适用边界和典型陷阱
EXISTS 在多数场景下比 IN 更容易触发外层索引，因为它只判断存在性，优化器常能把关联条件下推到子查询内：
- 正确写法是
WHERE EXISTS (SELECT 1 FROM logs WHERE logs.user_id = t.id AND logs.status = 1)；注意子查询里必须显式引用外层字段（t.id），否则变成非相关子查询，可能更慢 - 如果子查询本身字段无索引（比如
logs.status没单独建索引），EXISTS仍会扫全表；得确保子查询中用于关联和过滤的字段都有合适索引 -
NOT IN遇到子查询任意一行是NULL，整个结果集为空；NOT EXISTS不受此影响，行为更可靠
DELETE / UPDATE 中的 IN 子查询为何特别容易失效
同一个子查询，在 SELECT 里可能被优化器自动转成 semi-join 并走索引，但在 DELETE 或 UPDATE 里却常退化为嵌套循环+全表扫描——这是 MySQL 5.7 的已知限制：
- 执行
EXPLAIN后再SHOW WARNINGS，你会发现SELECT版本被重写为semi join，而DELETE版本没有；这不是 bug，是 DML 语句的优化路径更保守 - 强制方案只有两个：
DELETE t1 FROM account AS t1 INNER JOIN old_account AS t2 ON t1.name = t2.name，或先用CREATE TEMPORARY TABLE缓存子查询结果再关联删除 - 临时表方式要小心磁盘临时表开销；若子查询结果不大（SELECT id INTO OUTFILE + 应用层生成
IN列表反而更快
为什么加了索引还是不走？检查变量类型和隐式转换
即使你把子查询改成了 JOIN，外层字段也建了索引，仍可能不走索引——常见于使用用户变量的场景：
- 用
SET @name = 'xxx'赋值后在查询中引用，MySQL 5.7 无法准确推断该变量类型，导致索引列与变量比较时发生隐式转换；EXPLAIN里会出现type: ALL或key: NULL - 必须显式声明变量类型：
DECLARE name VARCHAR(255); SET name = 'xxx';，才能让优化器识别匹配路径 - 同理，子查询中若对索引字段用了函数（如
UPPER(name)），或连接条件两边字段类型不一致（如VARCHARvsCHAR），也会触发隐式转换并丢弃索引
最易被忽略的一点：MySQL 5.7 对子查询的物化不是默认行为，哪怕你加了 /*+ MATERIALIZE */ 提示，它也可能忽略——别依赖提示，优先用 JOIN 或 EXISTS 显式控制执行逻辑。
