UNION 是行堆叠操作，要求列数和类型兼容，用于合并结构相同、来源不同的结果集；JOIN 是列拼接操作，依赖关联字段对齐不同维度数据，实现行级逻辑关联。
UNION 和 JOIN 的本质区别在哪
不是“用哪个更好”，而是“它们根本不是同一类操作”。UNION 合并的是查询结果集（行堆叠），JOIN 关联的是表之间的逻辑关系（列拼接）。选错就等于把“把两摞书叠起来”和“把一本书的目录页和内容页订在一起”混为一谈。
常见错误现象：SELECT a.id, a.name FROM users UNION SELECT b.order_id, b.amount FROM orders —— 直接报错，因为列数、类型不兼容；而 SELECT u.name, o.amount FROM users u JOIN orders o ON u.id = o.user_id 才是合法关联。
-
UNION要求每个SELECT的列数一致、对应列类型兼容（如INT和TINYINT可隐式转换，但VARCHAR和DATE不行） -
JOIN不要求列数相同，但必须有明确的关联字段（比如ON a.id = b.user_id），且该字段最好有索引 - 列名以第一个
SELECT为准：SELECT name FROM t1 UNION SELECT full_name FROM t2，结果列名是name，不是full_name
什么时候必须用 UNION（而不是 JOIN）
当你需要把“结构相同、来源不同”的数据合并在一个结果里，且不关心行之间是否有关联。典型场景是分表归档、多租户数据合并、跨时间分区查询。
例如：查 2022 年和 2023 年的活跃用户，两张表结构完全一样：
SELECT user_id, login_date FROM user_active_2022 UNION ALL SELECT user_id, login_date FROM user_active_2023;
注意：UNION ALL 比 UNION 快得多，除非你真需要去重——去重会触发临时排序，大数据量时明显拖慢响应。
- 别用
UNION去“补全缺失字段”：比如想把用户表和订单表强行拼成宽表，那是JOIN的事 - 如果两个
SELECT的列顺序不一致（比如一个是id, name，另一个是name, id），结果会错位，且不会报错，只默默按位置匹配 - NULL 值在
UNION中是合法值，但参与去重时会被视为相等（NULL = NULL在UNION中成立）
什么时候必须用 JOIN（而不是 UNION）
当你需要把“不同维度的信息”按业务实体对齐到同一行。比如一条订单记录，既要金额，也要下单人姓名、收货地址、商品名称——这些信息分散在多个表中，靠外键关联，不能靠堆叠解决。
例如：查最近一周订单 + 用户真实姓名 + 所属城市：
SELECT o.order_no, u.real_name, a.city FROM orders o JOIN users u ON o.user_id = u.id JOIN addresses a ON u.id = a.user_id WHERE o.create_time >= '2026-07-29';
这里 JOIN 是刚性依赖：没有 ON 条件就语法错误；少一个 JOIN 就漏掉关键字段；用 UNION 完全无法表达这种行级对齐关系。
-
LEFT JOIN保留左表全部行，右表无匹配则填NULL；但若在WHERE中过滤右表字段（如WHERE a.city = 'Beijing'），会把原本应保留的左表行也过滤掉——得写成ON ... AND a.city = 'Beijing' -
INNER JOIN等价于JOIN，但显式写出更易读；别指望它自动处理一对多——一条用户记录可能对应多条订单，结果行数会膨胀 - 笛卡尔积风险：漏写
ON条件或条件恒真（如ON 1=1），会导致结果行数 = 左表行数 × 右表行数，小表看不出问题，大表直接 OOM
容易被忽略的性能与语义陷阱
真正踩坑的地方不在语法，而在“以为自己懂了，其实没想清数据逻辑”。比如用 UNION ALL 合并两个子查询，却忘了其中一个带 ORDER BY ——UNION 整体的排序必须放在最后，子查询里的 ORDER BY 无效（除非配合 LIMIT，但意义已变）。
-
UNION的去重开销常被低估：即使两结果集本身无重复，数据库仍要执行哈希或排序去重，UNION ALL可省掉这步 -
JOIN的关联字段没索引？查 10 万行订单关联用户，可能从毫秒级变成秒级——尤其LEFT JOIN，右表扫描无法跳过 - 混合使用时特别危险：比如先
JOIN再UNION，或嵌套UNION后再JOIN，可读性暴跌，执行计划难优化，出问题很难定位
