MySQL根本不支持FULL JOIN，是官方明确不实现的设计决策，执行即报ERROR 1064；需用LEFT JOIN加NOT EXISTS与UNION ALL拼接右表独有数据，并注意NULL处理、字段对齐及类型声明。
MySQL 根本不支持 FULL JOIN，不是版本问题，是官方明确不实现——写就报错 ERROR 1064。
MySQL 解析器直接拒绝识别 FULL JOIN 关键字
你执行 FULL JOIN 或 FULL OUTER JOIN 时，MySQL 在语法解析阶段就失败，根本不会进入查询优化或执行环节。这不是兼容性开关能打开的，也不是你少写了括号或引号的问题。从 5.7 到 8.0.32（截至 2026 年 6 月），所有官方版本都压根没注册这个 token。
-
FULL JOIN不是 MySQL 的保留字，词法分析器直接报ERROR 1064 (42000): You have an error in your SQL syntax -
UNION JOIN同样不存在，是常见幻觉——SQL 标准里没这个词，各数据库也无实现 - 别指望用配置项、插件或隐藏参数启用，它属于“设计上就不做”
SQL Server 旧兼容模式下 FULL JOIN 失效是解析器硬限制
在 SQL Server 中，FULL JOIN 从 2008 版本（兼容级别 100）才正式支持。设为 80（SQL Server 2000）或 90（2005）时，T-SQL 解析器根本不认识 FULL 这个 JOIN_TYPE，连词法扫描都过不去。
- 错误信息是
Msg 156, Level 15, State 1: Incorrect syntax near 'FULL'，属于编译期错误 - 即使动态拼接 SQL 字符串绕过语法检查，执行引擎也没有
Hash Full Join算子可用 - 升级兼容级别是最直接解法；若不能升级，只能用
LEFT JOIN + RIGHT JOIN + UNION ALL手动模拟
为什么主流数据库选择不实现？不是技术做不到，而是权衡结果
FULL JOIN 在 ANSI SQL:1999 才成为核心特性（F401），此前属于可选扩展。MySQL 和早期 SQL Server 选择跳过，主要基于三点：
- 业务中真实需要全外连接的场景极少，多数可用
LEFT JOIN加应用层补漏替代 - 执行开销大：需全表扫描 + 大量 NULL 填充，对大表易成性能瓶颈
- 语义易引发误解：比如
WHERE amount > 100会静默过滤掉右表独有行（amount为 NULL），结果偏离预期
字段允许 NULL 时，手动模拟 FULL JOIN 极易漏数据
这是最容易被忽略的坑。当你用 NOT EXISTS 或 LEFT JOIN ... WHERE left.id IS NULL 提取右表独有行时，如果连接字段本身可为 NULL（比如 employees.department_id 允许 NULL），那么 ON e.department_id = d.id 永远不成立（因为 NULL = anything 返回 UNKNOWN），整个右表独有部分都会消失。
- 不能靠改
ON条件解决，得提前清洗或用COALESCE(e.department_id, -1) = COALESCE(d.id, -1)这类兜底逻辑 - 但要注意 -1 是否在业务主键中真实存在，否则会误匹配
- 更稳妥的做法是：先用
WHERE department_id IS NOT NULL过滤，再做连接
真正麻烦的从来不是怎么写那几行 SQL，而是连接键质量、NULL 语义和字段类型对齐——这些细节一错，结果集就 quietly 错了。
