JOIN顺序影响I/O而非仅CPU，是因为驱动表每行触发被驱动表一次独立磁盘访问；若被驱动表无索引，10万行驱动将引发10万次随机I/O，导致缓存失效、数据页反复读取。
为什么JOIN顺序会影响I/O，而不是只影响CPU？
数据库执行JOIN时，驱动表（outer table）的每一行，都要去被驱动表（inner table）里找匹配项。如果驱动表有10万行，而被驱动表没索引，那就要做10万次全表扫描——每次都是随机IO，缓存几乎失效。I/O压力来自“重复读取同一张大表的大量数据页”，不是来自JOIN逻辑本身。
优化器确实会尝试重排顺序，但它依赖统计信息；一旦统计过期、或表大小估算严重偏差（比如分区表只查最近分区但优化器按全量估算），它就可能选错驱动表，导致本该走ref变成ALL。
如何用EXPLAIN确认当前驱动表是否合理？
别只看SQL写了几个表，要看EXPLAIN输出中rows列和type列的实际值：
-
type = ALL且rows远大于该表实际符合条件的行数 → 这个表大概率被当成了被驱动表，且没走索引 - 驱动表的
rows应该明显小于其他表（比如100 vs 50000）→ 如果相反，说明优化器误判了 -
Extra里出现Using join buffer→ 内存不够，开始用磁盘模拟哈希连接，I/O已失控
示例：EXPLAIN SELECT * FROM logs l JOIN users u ON l.user_id = u.id WHERE l.created_at > '2026-06-01'，若logs的type是range（走了索引），但users是ALL，那就该让users当驱动表——哪怕它物理更大，只要加了WHERE u.status = 'active'能筛掉99%数据。
什么时候该用STRAIGHT_JOIN强制顺序？
STRAIGHT_JOIN不是银弹，只在明确知道优化器错了、且你手上有真实数据分布证据时才用：
- 小结果集表（如
SELECT * FROM regions WHERE country = 'CN'只返回3条）必须放在FROM后第一位，后面跟大表 - 业务逻辑要求某张表必须先过滤（比如权限校验表
user_perms，必须先确认用户有权限，再查主数据） - 临时表或CTE结果集已知很小，想确保它当驱动表 →
SELECT STRAIGHT_JOIN ... FROM (SELECT ...) t JOIN big_table b ON ...
注意：STRAIGHT_JOIN会绕过优化器所有成本估算，如果后续数据分布突变（比如regions突然新增200个国家），查询可能直接恶化。上线前必须用真实数据量压测。
真正容易被忽略的I/O放大点：JOIN后没及时投影
很多人以为“顺序对了、索引有了”就万事大吉，但SELECT *会让数据库把所有JOIN出来的列都读进内存，哪怕最后只用其中2列。尤其当大表有TEXT/BLOB字段，或宽表（50+列）参与JOIN时，一次IO可能读几十MB无用数据。
更隐蔽的是：JOIN放大后，DISTINCT或GROUP BY会触发Using temporary，临时表写入磁盘——这比JOIN本身更伤I/O。
所以，人为控制顺序的同时，必须同步收紧SELECT列表，并把聚合/去重逻辑尽量下推到子查询里。比如不要写SELECT DISTINCT u.name, o.amount FROM users u JOIN orders o...，而是先SELECT u.name FROM users u WHERE ...，再用IN或EXISTS关联订单统计。
