MySQL全连接（FULL OUTER JOIN）的“曲线救国”方案
先说一个让不少开发者感到困惑的事实：在相当长的时间里，MySQL对标准SQL中的FULL OUTER JOIN语法是“视而不见”的。直接使用会触发语法错误，这并非你的代码有问题，而是数据库引擎本身不支持。直到8.0.29版本，情况才有所改变，但默认仍是关闭状态，需要手动开启一个优化器开关。相比之下，PostgreSQL、SQL Server等数据库对此功能的支持就“原生”得多。
MySQL 为什么没有 FULL OUTER JOIN
原因很简单：在8.0.29版本之前，MySQL的设计中压根就没有为FULL OUTER JOIN预留位置。执行相关语句会直接报错：ERROR 1064 (42000): You ha ve an error in your SQL syntax。这算是MySQL一个比较特立独行的选择，毕竟其他主流数据库早就支持了。因此，开发者们不得不摸索出一套“组合拳”来模拟实现全连接的效果。
用 LEFT JOIN + RIGHT JOIN + UNION 拼出全连接效果
那么，如何用现有的工具拼出全连接呢？核心思路并不复杂：先用LEFT JOIN抓住“左表有、右表无”的数据，再用RIGHT JOIN覆盖“右表有、左表无”的情况，最后用UNION把两部分结果合并起来，并自动去除重复的交集行。这里有个关键点：LEFT JOIN和RIGHT JOIN的结果各自已经包含了两个表的交集部分，所以直接用UNION合并即可，无需再额外添加INNER JOIN。
实际操作时，有三个细节必须盯紧：
- 字段对齐是铁律：
UNION要求前后两个SELECT语句的列数、顺序和数据类型必须完全一致。如果某张表缺少对应字段，必须用NULL AS column_name来显式补位。 - 慎用UNION ALL：虽然
UNION ALL不进行去重，速度更快，但它会导致交集行被重复计算（因为左右连接各包含一次）。因此，要实现精确的全连接，必须使用UNION。 - 连接条件类型要匹配：
ON a.id = b.user_id这样的条件，如果两边的字段类型不一致（例如INT对VARCHAR），MySQL可能会进行隐式类型转换，这往往会导致索引失效，严重影响性能。
来看一个查询用户表和订单表的经典示例：
SELECT u.id, u.name, o.order_id, o.amount FROM users u LEFT JOIN orders o ON u.id = o.user_id UNION SELECT u.id, u.name, o.order_id, o.amount FROM users u RIGHT JOIN orders o ON u.id = o.user_id;
NULL 值处理和字段对齐是最大坑点
模拟方案最大的“坑”，往往藏在细节里。左右连接中，缺失一侧的字段值会以NULL填充，这本身符合预期。但问题在于，开发者很容易在编写第二个SELECT语句时，忘记与第一个语句的字段列表保持严格一致。
市场上不乏这样的翻车案例：
- 一边选了
u.id, u.name, o.order_id，另一边却漏掉了o.order_id，或者误写成了o.id，结果就是Column count doesn't match错误。 - 为了图快使用了
UNION ALL，事后才发现结果集中所有匹配的行都出现了两次，数据量直接翻倍。 - 连接条件中混用了字符串和数字类型，MySQL的隐式转换不仅让优化器无法使用索引，还可能导致匹配结果出现偏差，数据准确性都难以保证。
性能比原生 FULL OUTER JOIN 差不少，别在大表上硬刚
必须承认，这种模拟方案的性能开销是显而易见的。它本质上需要执行两次表连接和一次结果集的去重合并，IO和内存压力都会倍增。对于十万行以下的数据量，或许还能接受；一旦面对百万级大表，性能瓶颈就会非常突出。
这时就需要一些更优的策略：
- 分步缓存，减少重复扫描：可以先用
CREATE TEMPORARY TABLE创建临时表，分别存储左连接和右连接的结果，并为临时表添加合适索引，最后再进行UNION操作。这能避免对原表进行多次全表扫描。 - 审视需求，避免过度使用：很多时候，业务并不需要真正的“全连接”。如果只是想找出“存在于A表但不存在于B表”的数据，直接用
NOT EXISTS或LEFT JOIN ... WHERE right_table.id IS NULL会更高效。 - 关注新版本特性：对于MySQL 8.0.29及之后的版本，虽然官方加入了
FULL OUTER JOIN语法支持，但默认是禁用的。需要通过在启动时设置--optimizer_switch='full_join=on'参数来开启。在生产环境修改此类参数务必谨慎，需要充分测试。
最后给个忠告：在任何模拟方案上线前，一定要用EXPLAIN FORMAT=TREE仔细分析执行计划。确保查询没有意外地退化成全表扫描——那个UNION操作符，有时候确实会把优化器给绕进去。
