MySQL优化器穷举left-deep连接顺序并选择最低成本路径，而非按SQL书写顺序执行；它依赖rows×filtered、索引、IO等统计信息估算代价，EXPLAIN显示的即最终物理顺序。
MySQL优化器会穷举left-deep连接顺序，不是按FROM后顺序硬执行
MySQL不把SQL书写顺序当执行指令，而是当成语义约束参考。它默认启用join order optimization，对所有合法的left-deep树形排列（比如A→B→C、A→C→B、B→A→C等）逐个估算成本，挑最低的那个。这个过程依赖rows、filtered、索引可用性、IO开销等统计信息，而不是你写的先后。
常见错误现象：在EXPLAIN里看到table列顺序和自己写的完全对不上，比如写了FROM orders JOIN users JOIN products，结果products排第一——说明优化器发现它过滤后只剩3行，而users有80万行且没索引，强行先连orders和users代价太高。
-
rows × filtered比单看rows更能反映实际参与JOIN的行数，是判断驱动表质量的关键指标 - LEFT JOIN会限制重排自由度，但不是禁止：若左表本身无有效过滤条件，优化器仍可能把右表物化后再反向匹配
- MySQL 8.0+支持
EXPLAIN FORMAT=TREE，能直接看到嵌套结构和哪张表是顶层驱动
ON条件写错位置会让优化器“看不见”右表的过滤能力
把本该在ON里的右表过滤条件挪到WHERE，不仅语义退化为INNER JOIN，还会让优化器误判：它以为右表必须全量加载，再做最后过滤，于是放弃把右表当驱动表的可能。
例如SELECT * FROM orders LEFT JOIN users ON orders.user_id = users.id WHERE users.status = 'active'，优化器看不到users.status = 'active'能在JOIN阶段就筛掉99%数据，只能假设要扫全量users表，自然不敢选它当驱动表。
- 正确写法是
LEFT JOIN users ON orders.user_id = users.id AND users.status = 'active' - 这种写法让
status成为JOIN条件的一部分，优化器可在range analysis阶段评估其选择性 - EXPLAIN的
Extra列若出现Using where且涉及右表字段，就是危险信号
STRAIGHT_JOIN能强制顺序，但绕过优化器的风险比想象中大
STRAIGHT_JOIN确实能让MySQL按FROM后顺序执行，但它完全跳过成本估算。一旦统计信息过期（比如没跑过ANALYZE TABLE），或者数据分布突变（如某天突然涌入百万新用户），它可能选一条比优化器原计划慢几个数量级的路径。
典型踩坑场景：开发环境数据量小，STRAIGHT_JOIN看起来快；上线后真实数据一跑，发现被驱动表全表扫描几十次，CPU直接打满。
- 只在明确知道最优路径、且统计信息最新时才用
STRAIGHT_JOIN - 对LEFT JOIN慎用
STRAIGHT_JOIN：它不能保证语义正确，比如强制先查右表可能导致NULL传播逻辑出错 - 替代方案更稳妥：用子查询提前过滤，或给关键字段建组合索引，让优化器自己愿意选你想要的顺序
书写顺序真正影响的是语义可见性和NULL传播逻辑
虽然物理执行顺序由优化器定，但SQL书写顺序决定了ON子句能引用哪些表、中间结果集如何形成、NULL如何向下传递。比如A LEFT JOIN B LEFT JOIN C ON B.id = C.b_id中，C只依赖B，不会去匹配A的NULL行；但如果写成A LEFT JOIN B LEFT JOIN C ON A.id = C.a_id，C就会错误地尝试匹配A每一行，包括B为NULL的那些。
也就是说，你写的顺序不控制机器怎么跑，但控制逻辑怎么算。一个括号、一个ON位置、一个WHERE挪动，都可能让结果集行数翻倍或归零。
- 多表LEFT JOIN时，每个
ON只约束紧邻右侧的表，不能跨表引用未引入的别名 - 想控制中间结果膨胀点，就把高选择性条件的表尽量写在JOIN链最左侧
- 真正难的不是让优化器听你的话，而是让它“想明白”你真正想表达的逻辑
