MySQL不支持FULL OUTER JOIN，包括多表链式写法，执行即报ERROR 1064；需用UNION ALL分步构造三表所有7种存在组合，并以COALESCE对齐主键，避免NULL歧义。
MySQL不支持多表FULL OUTER JOIN语法，必须拆解
直接写 FULL OUTER JOIN 连三个表（比如 A FULL OUTER JOIN B FULL OUTER JOIN C）在 MySQL 中会报错 ERROR 1064。PostgreSQL、SQL Server 等虽支持两表 FULL OUTER JOIN，但对三表及以上仍无标准语法——所谓“链式全连接”本质是数据库未定义的行为，不同引擎解析逻辑不一致，Presto 允许写，但结果依赖“关键表”顺序（见后文），不可靠。
真正可落地的做法只有一种：把多表全连接视为「两两全连接的递进合并」，用 UNION ALL + LEFT JOIN/RIGHT JOIN 手动构造每张表的“独有行”，再按主键/业务键 COALESCE 对齐。
用UNION ALL模拟三表FULL OUTER JOIN的核心步骤
以三张表 a、b、c 为例，假设它们都通过 (e, f, g) 三字段联合标识一条记录：
- 先做
a LEFT JOIN b，再WHERE b.e IS NULL拿出 a 独有行 - 再做
b LEFT JOIN a，再WHERE a.e IS NULL拿出 b 独有行 - 同理处理
c与a、c与b的独有部分 - 最后把所有匹配行（
a JOIN b JOIN c）和全部独有行UNION ALL起来 - 最终 SELECT 中用
COALESCE(a.e, b.e, c.e)等统一主键列，避免 NULL 冲突
注意：不能简单套用两表模拟的 LEFT + RIGHT WHERE IS NULL 模式，因为三表存在“仅 a&b 匹配但 c 不匹配”这类中间态，必须显式枚举所有 7 种存在组合（2³−1）。
Presto中写FULL OUTER JOIN链式语法的风险点
像 Presto 这类支持 FULL OUTER JOIN 链式的引擎，写法看似简洁：
SELECT COALESCE(a.e, b.e, c.e) AS e, ... FROM a FULL OUTER JOIN b ON a.e = b.e AND a.f = b.f AND a.g = b.g FULL OUTER JOIN c ON a.e = c.e AND a.f = c.f AND a.g = c.g
但结果严重依赖 ON 条件中「哪张表作为左操作数」：
- 若第二层
ON用a.e = c.e，则 b 和 c 的相同主键可能分散在不同行（因 a 是锚点，c 只跟 a 对齐） - 若改用
b.e = c.e，b 和 c 的匹配行就会合并到同一行（b 成为锚点） - 这意味着：**链式写法没有全局唯一对齐语义，结果不可预测，除非你明确控制锚定表顺序**
实际建模时更推荐的替代方案
多数真实场景下，硬要三表全连接往往暴露了模型设计问题。比起拼接，优先考虑：
- 用一张宽表（如事实表 + 维度退化）替代多次 JOIN，减少运行时复杂度
- 用 CTE 预先
UNION ALL三张表的主键集，再分别LEFT JOIN各自字段，逻辑清晰且易调试 - 如果只是做数据比对（比如找缺失记录），分三次执行两两
FULL OUTER JOIN更安全，避免COALESCE引入歧义
最常被忽略的一点：FULL OUTER JOIN 的结果集天然稀疏（大量 NULL），一旦涉及聚合或后续计算，NULL 处理逻辑极易出错——宁可多写几行明确的 CASE WHEN，也不要依赖 COALESCE 的隐式对齐。
