LEFT JOIN顺序不可随意交换，因语义强制左表全保留，优化器无法重排；应将过滤后结果集最小的表置左，右表ON字段须建索引，且右表过滤条件必须写在ON中而非WHERE里。
JOIN顺序本身不改变INNER JOIN的语义结果，但会显著影响优化器生成的执行计划——尤其当表大小、过滤强度、索引覆盖存在差异时，错误的顺序可能让大表被迫成为驱动表，引发海量随机I/O。
EXPLAIN里哪几列暴露了实际驱动表
执行EXPLAIN ANALYZE后，重点盯三处：
-
rows列：驱动表对应行数应明显更小（不是原始表行数，而是WHERE过滤后的预估行数） -
type列：被驱动表的理想值是ref、eq_ref或range；若出现ALL，说明它被全表扫描了 -
Extra列：出现Using join buffer或Using temporary，基本意味着中间结果集失控，顺序很可能错了
LEFT JOIN为什么不能随便换左右顺序
LEFT JOIN的语义强制左表数据必须全部保留，优化器无法像INNER JOIN那样自由交换左右表来选驱动表。这意味着：
- 即使右表更小、索引更好，优化器也不能把它拉到外层循环位置
- 如果左表没加有效WHERE条件（比如
WHERE a.created_at > '2026-01-01'），它就大概率变成事实上的驱动表——哪怕它有千万行 - 把右表的过滤条件写在
WHERE里（如WHERE b.status = 'active'）会悄悄退化为INNER JOIN，还可能误导优化器误判选择率
正确做法是把右表过滤移到ON子句：LEFT JOIN b ON a.id = b.a_id AND b.status = 'active'。
什么时候该用STRAIGHT_JOIN或/*+ Leading() */
这些强制手段只在明确知道优化器选错时才用，不是常规解法：
- MySQL用
STRAIGHT_JOIN：当EXPLAIN显示驱动表rows远大于被驱动表，且你确认左表过滤后确实更小 - PostgreSQL用
/*+ Leading(t1 t2 t3) */提示（需启用pg_hint_plan）：多表JOIN时优化器因组合爆炸放弃穷举，而你通过业务逻辑能确定最优路径 - Oracle用
/*+ leading(a b c) */：同理，但要注意leading指定的是驱动顺序，不是语法顺序 - 所有强制手段都必须配合
ANALYZE TABLE或VACUUM ANALYZE更新统计信息后再验证，否则可能越调越差
真正决定性能的不是“谁在左边”，而是“谁先被扫”
新手常误以为“把小表写在FROM后面第一个JOIN位置就万事大吉”，但现实更复杂：
- 如果小表没索引、或者JOIN字段类型不一致（如
INTvsVARCHAR），优化器可能直接弃用它作驱动表 - 如果大表带强过滤（
WHERE status = 'done' AND created_time > '2026-03-01'），它过滤后只剩几百行，那它才是事实上的“小表” - 复合索引顺序必须匹配使用模式：例如
WHERE u.city = 'Beijing' AND u.id = o.user_id，索引就得建(city, id)，而不是(id, city)
最易被忽略的一点：驱动表的JOIN字段本身不需要索引，但被驱动表的对应字段必须有——否则每次匹配都要全表扫一遍。
