会影响，而且影响可能非常大——但不是因为“SQL怎么写的”，而是因为优化器实际选了哪个表做驱动表；LEFT JOIN语义强制左表为驱动表，若其过滤后结果集过大或右表缺索引，会导致全表扫描和嵌套循环膨胀。
会影响，而且影响可能非常大——但不是因为“SQL怎么写的”，而是因为优化器实际选了哪个表做驱动表。
EXPLAIN里哪几列暴露了真实驱动表
别看FROM后面怎么排，直接看执行计划：
-
rows列：驱动表对应的预估行数应该明显更小（注意是WHERE过滤后的结果集大小，不是原表总行数） -
type列：被驱动表的理想值是ref、eq_ref或range；如果出现ALL，说明它被全表扫描了，大概率成了事实上的驱动表 -
Extra列：出现Using join buffer或Using temporary，基本意味着中间结果失控，JOIN顺序很可能错了
LEFT JOIN为什么不能随便换左右顺序
LEFT JOIN的语义强制左表必须全保留，优化器通常不敢重排——哪怕右表只有10行、左表有1000万行，它也不会把右表拉到外层循环位置。
- 如果左表没加有效
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时优化器因组合爆炸放弃穷举，而你通过业务逻辑能确定最优路径 - 所有强制手段都必须配合
ANALYZE TABLE或VACUUM ANALYZE更新统计信息后再验证，否则可能越调越差
真正难的不是“怎么写顺序”，而是判断“哪个才是事实上的小表”——它可能是大表加了强过滤后的结果集，也可能是CTE里提前聚合出来的中间表。优化器看不到你脑子里的业务逻辑，只能靠统计信息和语法结构猜。
