17370845950

UNION用于纵向合并多个SELECT结果集，要求列数一致、类型兼容，列名以首个SELECT为准；UNION去重，UNION ALL保留重复，性能更优；不可在分支中用ORDER BY/LIMIT，需整体排序；不适用于跨表关联，应使用JOIN。

UNION 是用来合并多个 SELECT 结果集的 SQL 操作符

它把几条 SELECT 语句查出来的行“摞在一起”，形成一个统一的结果集。不是连接（JOIN）那种横向拼字段，而是纵向堆记录——就像把几张结构相同的 Excel 表，从第二行开始往下粘贴成一张大表。

UNION 和 UNION ALL 的关键区别

默认的 UNION 会自动去重；UNION ALL 则原样保留所有行，包括完全重复的。

• 要严格去重（比如合并两个部门员工名单，避免同一个人出现两次）→ 用 UNION
• 明确知道无重复，或压根不需要去重（比如日志分表查询、分页拉取多批次数据）→ 用 UNION ALL，性能更好
• MySQL 不支持 UNION 后直接跟 LIMIT 或 ORDER BY（除非整个联合结果再套一层子查询），但 ORDER BY 可以放在最后整体加，例如：

  SELECT id, name FROM employees
  UNION
  SELECT id, name FROM contractors
  ORDER BY name;

必须满足的硬性条件，否则直接报错

MySQL 对 UNION 要求非常严格，不满足就抛 Error 1222 (21000): The used SELECT statements have a different number of columns 或类似类型错误。

• 每个 SELECT 的列数必须一致
• 对应位置的列，数据类型最好兼容（比如 VARCHAR 和 CHAR 可隐式转换，但 INT 和 JSON 就不行）
• 列名以第一个 SELECT 为准，后续语句的别名不会生效（想统一列名，只能在第一个里起）
• 不能在单个分支里写 ORDER BY 或 LIMIT（语法不允许），除非用括号包成子查询

常见误用场景和替代思路

有人试图用 UNION 实现“左表全量 + 右表匹配字段”，这其实是 LEFT JOIN 的职责——UNION 处理的是“同类数据的并集”，不是“跨表关联”。

• 想查「用户表」+「文章表」中所有活跃 ID？→ 确保两表都输出 id, name, type 这类对齐字段，用 UNION 合并
• 想查「用户信息 + 他发的文章标题」？→ 必须用 JOIN，不是 UNION
• 遇到 Error 1630 (42000): FUNCTION xxx does not exist？检查是否误把函数名当表名用了（比如写了 SELECT SUM(num) FROM sum，MySQL 把 sum 当成表了）

真正容易被忽略的一点：UNION 的执行顺序是“先各自执行 SELECT，再合并去重”，所以它无法利用索引下推优化跨分支逻辑；如果数据量大且有复杂过滤，优先考虑视图、临时表或应用层合并，而不是硬扛 UNION。