MySQL 5.7及更早版本子查询性能差的主因是缺乏物化和半连接优化，导致WHERE id IN (SELECT...)被当作相关子查询反复执行，而等价JOIN可利用索引将复杂度从O(N×M)降至O(N×log M)。
MySQL 5.7 及更早版本的子查询执行机制是根本原因
低版本 MySQL 对子查询缺乏成熟的物化（materialization）和半连接（semi-join）优化能力。遇到 WHERE id IN (SELECT ...) 这类常见写法时，优化器默认走的是「相关子查询」路径：外层每扫描一行，内层就重新执行一次完整子查询。如果 orders 表有 10 万行，而子查询又没索引，那就是 10 万次全表扫描 customers ——I/O 和 CPU 开销直接爆炸。
相比之下，JOIN 在这些版本中早已稳定支持嵌套循环连接（NLJ），只要被驱动表的关联字段（如 customer_id）上有索引，就能做到单次索引查找匹配，整体复杂度从 O(N×M) 降到接近 O(N×log M)。
EXPLAIN 中 type=DEPENDENT SUBQUERY 是明确信号
执行 EXPLAIN 后，如果子查询对应的行显示 type 为 DEPENDENT SUBQUERY，基本可判定它正在被反复执行。这种执行计划里通常还伴随：
-
rows值异常高（尤其是子查询所在行的rows接近全表行数） -
Extra列出现Using where; Using index但没Using join buffer - 没有
Materialized或Semi-join相关提示
而等价的 JOIN 写法，同一语义下大概率显示 type=ref 或 type=eq_ref，且 key 列明确指出用了哪个索引。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
物化临时表在低版本中不可控且代价高
即使你希望子查询结果被一次性算出并缓存，5.7 之前也做不到智能物化。手动加 /*+ MATERIALIZE */ 提示不被支持；强行用派生表（FROM (SELECT ...) AS t）又会立即生成无索引的磁盘临时表，尤其当子查询含 GROUP BY 或 ORDER BY 时，性能反而更差。
关键限制包括：
- 派生表无法自动建索引，后续关联只能全表扫描
- 临时表默认使用 MyISAM 引擎（5.6）或 MEMORY（5.7），但字段长度超限就退化为 MyISAM 磁盘表
- 没有统计信息反馈，优化器无法基于物化结果重估成本
为什么不是所有 JOIN 改写都安全？
盲目替换可能引入语义错误或放大结果集：
- 原
IN子查询天然去重，INNER JOIN若存在一对多关系（如一个客户有多笔订单），会导致主表行重复，COUNT(*)或SUM()出错 - 原
NOT IN遇到NULL返回空集，而LEFT JOIN ... IS NULL才能等价，且必须确保关联字段非空或加额外IS NOT NULL条件 - 子查询带
LIMIT或ORDER BY（如取每个用户的最新订单），硬转JOIN会丢失排序逻辑，必须配合窗口函数或分组聚合，复杂度陡增
真正容易被忽略的点是：**改写前先确认子查询是否真的“相关”——如果子查询里没引用外层表字段，它本就是独立可物化的，但在低版本里仍可能被误判为依赖型，这时加 /*+ NO_MERGE() */ 或升级到 8.0 才是最轻量解法。**
