sql多表JOIN的逻辑执行顺序是从左到右嵌套结合，即A JOIN B JOIN C等价于(A JOIN B) JOIN C；ON条件仅作用于当前JOIN的两张表；LEFT JOIN中左表始终为左侧中间结果，NULL行仍参与后续JOIN。
SQL 中多表 JOIN 的执行顺序，不是按 SQL 语句中 FROM 和 JOIN 的书写顺序线性执行，而是由查询优化器决定的。但理解其逻辑执行顺序（即语义顺序），对写出正确、高效、可维护的 SQL 至关重要。
JOIN 是从左到右“嵌套”结合的
在标准 SQL（如 postgresql、SQL Server、mysql 8.0+ 的 ANSI 模式）中，多个 JOIN 默认按**从左到右的结合性**进行语义解析，即 LEFT JOIN B JOIN C 等价于 (A JOIN B) JOIN C，而非 A JOIN (B JOIN C)。
- 这意味着中间结果集会先生成 A ⨝ B，再用该结果与 C 进行 JOIN
- 如果使用括号显式分组，如
A JOIN (B JOIN C)，则优先计算 B ⨝ C - 不同数据库对括号支持程度略有差异，但逻辑结合规则一致
ON 条件只作用于当前 JOIN 的两张表
每个 JOIN 后的 ON 子句仅能引用该 JOIN 左右两侧的表（或已出现在左侧中间结果中的列），不能提前引用后续才 JOIN 进来的表。
- 例如：
FROM A JOIN B ON A.id = B.a_id JOIN C ON B.id = C.b_id✅ 合法 - 而：
FROM A JOIN B ON A.id = C.a_id JOIN C ON ...❌ 报错：C 在第一个 ON 时尚未引入 - 若需跨多表关联条件，可改用 WHERE（但注意 LEFT JOIN 下 WHERE 过滤可能转为 INNER 效果）
LEFT JOIN 的“左表驱动”特性影响结果行数
LEFT JOIN 保证左表所有行出现在结果中，右表匹配失败则补 NULL。当连续使用多个 LEFT JOIN 时，左表始终是整个左侧中间结果，不是原始 A 表。
-
A LEFT JOIN B LEFT JOIN C中，即使 B 某行为 NULL，C 仍会尝试与该 NULL 行“匹配”（通常无匹配，C 列全 NULL） - 若希望 C 只匹配 B 的非 NULL 行，应写成：
A LEFT JOIN B LEFT JOIN C ON B.id = C.b_id（ON 中明确依赖 B） - 错误写法：
A LEFT JOIN B LEFT JOIN C ON A.id = C.a_id—— C 会错误地尝试匹配 A 的每一行，包括 B 为 NULL 的行
优化器可能重排物理执行顺序，但语义不变
数据库优化器会根据统计信息、索引、行数估算等，选择最优的物理执行计划（如先算 B ⨝ C 再连 A），只要最终结果与逻辑顺序一致即可。
- 可通过
EXPLaiN（MySQL/PostgreSQL）或SHOW PLAN_ALL（SQL Server）查看实际执行计划 - 书写顺序 ≠ 执行顺序，但书写顺序决定了语义约束（如 ON 可见性、NULL 传播逻辑）
- 为提升可读性和可控性，建议：显式括号分组 + 将驱动表放最左 + 复杂关联拆到子查询