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字段类型不一致（如INT vs VARCHAR），优化器可能直接弃用它作驱动表
• 如果大表带强过滤（WHERE status = 'done' AND created_time > '2026-03-01'），它过滤后只剩几百行，那它才是事实上的“小表”
• 复合索引顺序必须匹配使用模式：例如WHERE u.city = 'Beijing' AND u.id = o.user_id，索引就得建(city, id)，而不是(id, city)

最易被忽略的一点：驱动表的JOIN字段本身不需要索引，但被驱动表的对应字段必须有——否则每次匹配都要全表扫一遍。