非关联子查询改写为join可提速，因其使优化器能选用hash join或物化+索引查找替代重复全表扫描，但需满足子查询结果小、主表大、连接字段无索引或存在隐式转换等前提。
非关联子查询写在 JOIN 中能提高速度，不是因为“语法变了”，而是它让优化器有机会用 Hash Join 或物化 + 索引查找替代反复全表扫描——前提是子查询结果小、主表大、连接字段无索引或存在隐式转换。
为什么非关联子查询容易被重写为 Hash Join
非关联子查询（如 WHERE x IN (SELECT y FROM t2 WHERE cond)）逻辑上不依赖外层行，优化器会把它识别为半连接（semi-join），并根据代价估算选择执行策略：
- 若子查询预估行数少（比如几百行）、主表连接列没索引，
Hash Join成为最优解：一次性把子查询结果哈希建表，主表顺序扫描一次即可匹配 - 若子查询带
ORDER BY或聚合，Merge Join可能被选中，但需双方已排序——实际中常因缺失排序而失效 - 若主表连接列有高效索引，
Index Nested-Loop可能更快，此时硬塞JOIN反而绕过索引
MySQL 8.0+ 中必须显式开启才能生效
MySQL 默认不自动对非关联子查询启用 Hash Join，需确认两个开关已打开：
optimizer_switch='materialization=on,hash_join=on'- 子查询必须能被物化（即不含
GROUP BY、ORDER BY、LIMIT等阻止物化的子句） - 执行计划里出现
Hash Join字样还不够，得看Extra列是否有Using hash，且rows值合理
最容易被忽略的“假加速”陷阱
看起来改成了 JOIN，EXPLAIN 也显示 Hash Join，但实际更慢，常见原因：
- 哈希表溢出到磁盘：PostgreSQL 中
Buffers: temp read/write值很大；MySQL 没直接指标，但Created_tmp_disk_tables暴涨就是信号 - 字符集/类型不一致导致无法走索引：比如
t1.status_code是VARCHAR，t2.code是INT，隐式转换让Hash Join成为唯一选择，但本可用索引快速定位 - 子查询结果其实不小（比如返回 5 万行），哈希建表内存吃紧，反而触发频繁 GC 或落盘，这时
MATERIALIZED+ 主表索引查找可能更稳
真正起效的关键不在“写成 JOIN”，而在你是否盯着 EXPLAIN ANALYZE 里的 Hash Cond、Buffers、loops 和实际执行时间——否则只是把慢换了个姿势。
