执行计划中的JOIN顺序由优化器根据行数、索引和选择率自动决定，并非按SQL书写顺序执行；WHERE与ON中条件位置不同会显著影响优化器决策和语义正确性；真实执行顺序需通过运行时执行计划（如Oracle的DBMS_XPLAN.DISPLAY_CURSOR）确认，而非EXPLAIN PLAN预估。

执行计划里的JOIN顺序由优化器决定，不是你写的顺序

数据库不会照着你写的 FROM t1 JOIN t2 JOIN t3 从左到右依次连表。优化器会评估每张表的行数、索引可用性、过滤条件选择率，然后选出代价最小的关联路径。比如你写的是 t1 JOIN t2 ON ... JOIN t3 ON ...，但执行计划可能先连 t2 和 t3（因为它们都有强过滤条件），再用结果去驱动 t1。

WHERE条件位置不影响JOIN执行顺序，但会影响优化器决策

你把 WHERE 写在 JOIN 后面，或挪到 ON 里，表面看只是语法位置变化，实际会极大改变优化器的判断依据：

• ON 中的条件（如 t1.id = t2.t1_id）用于控制连接时保留哪些行，直接影响中间结果集大小
• WHERE 中的条件（如 t1.status = 'active'）是在连接完成后才过滤，若该字段有索引，优化器可能选择先用它单表扫描，再做嵌套循环连接
• 把本该写在 WHERE 的过滤条件错误塞进 ON（尤其在 LEFT JOIN 中），会导致语义错误——t2 字段为 NULL 的行也可能被意外排除

查看真实执行顺序，别信EXPLAIN PLAN的预估

你在工具里点“执行计划”看到的，大概率是 EXPLAIN PLAN 生成的预估计划，它依赖过期统计信息、未绑定的实际参数值，甚至会忽略当前会话的 optimizer_mode 设置。真正可靠的顺序，得靠实际执行后查 V$SQL_PLAN（Oracle）或 sys.dm_exec_query_plan（SQL Server）：

• Oracle：执行 SQL 后立即运行 SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(null, null, 'ALLSTATS LAST'));
• MySQL：加 /*+ SET_VAR(use_secondary_engine=OFF) */ 提示并开启 performance_schema，再查 performance_schema.events_statements_history_long
• PostgreSQL：用 EXPLAIN (ANALYZE, BUFFERS)，注意看 Actual Startup Time 和 Actual Total Time 列

多表JOIN时最容易被忽略的陷阱

三个及以上表关联时，执行顺序的不可控性会指数级放大：

• 即使你强制用 STRAIGHT_JOIN（MySQL）或 ORDERED hint（Oracle），也只约束关联方向，不保证物理读取顺序
• 不同数据库对“驱动表”的定义不同：MySQL 通常选过滤后结果最少的表为驱动表；Oracle 更倾向用主键/唯一索引字段做驱动
• JOIN 顺序和 WHERE 条件的组合，可能让优化器放弃使用某个本该生效的索引——比如 t1.a = t2.b AND t2.c > 100，若 t2.c 上有索引但 t2.b 没有，优化器可能选择全扫 t2 再哈希匹配

真正影响性能的从来不是你写了几个 JOIN，而是每一步中间结果集的大小和是否能走索引。盯着执行计划里的 Rows 和 Cost 列，比纠结书写顺序实在得多。