相关子查询导致I/O爆炸，因MySQL 5.7及更早版本不对相关子查询物化，外层每行都重执行内层扫描；10万用户即触发10万次orders全表扫描，I/O线性翻倍。JOIN通过Hash Join或BNL将分散I/O收敛为单次批量处理，但需确保连接字段有索引且过滤条件置于ON子句中。
相关子查询为什么导致I/O爆炸
因为MySQL 5.7及更早版本对相关子查询（如WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id)）基本不做物化，而是为外层表每一行都重新执行一次内层扫描。如果users表返回10万行，而orders表没有user_id索引，那就要做10万次全表扫描——每次都是独立的磁盘随机读或顺序扫，I/O请求量直接线性翻倍。
即使有索引，也常因优化器无法下推条件（比如o.status = 'paid'被锁在子查询里），导致索引实际只用到user_id字段，后续过滤仍靠回表或临时内存计算。
JOIN如何把多次I/O压成一次批量处理
改写为INNER JOIN orders o ON u.id = o.user_id AND o.status = 'paid'后，优化器有机会启用Hash Join（MySQL 8.0+）或Block Nested-Loop（BNL）：前者把小表（如users）哈希进内存，大表（orders）只扫描一次；后者用join_buffer批量缓存驱动表多行，减少被驱动表重复定位次数。
关键不是“JOIN天生快”，而是它把原本分散的、不可预测的I/O请求，收敛成可控的、可批量的访问模式。
- 必须确保连接字段有索引：
users.id和orders.user_id都得有单列或联合索引，否则BNL退化为普通NLJ，I/O反而更糟 -
AND o.status = 'paid'这类条件要写在ON子句里，而不是WHERE，才能参与连接前的预过滤 - 若
orders是明显的大表，应设为被驱动表；users作为驱动表更利于join_buffer利用
EXPLAIN里看I/O压力是否真降了
对比改写前后的EXPLAIN输出，重点关注三处：
-
type列：从ALL或index变成ref或eq_ref，说明走了索引查找，而非全表扫 -
rows列：外层表估算行数不变，但内层表的rows应显著下降（比如从20万降到300），代表剪枝有效 -
Extra列：消失Using where; Using temporary; Using filesort，尤其避免Using temporary——它意味着大量磁盘临时表I/O
真正容易被忽略的是：JOIN后若产生一对多膨胀（比如1个用户对应5条订单），SELECT *会把同一用户数据复制5次传输，网络和内存I/O也会涨。这时候该用DISTINCT或提前聚合，而不是只盯着磁盘I/O。
