UNION自动去重并隐式排序，UNION ALL仅拼接不查重、不排序，性能通常快2–5倍；二者均要求各SELECT列数相同、对应列类型兼容，ORDER BY和LIMIT须置于整个UNION语句末尾。
UNION 和 UNION ALL 的核心区别必须先搞清
用 UNION 还是 UNION ALL，直接决定性能和结果是否去重。不是“哪个更好”，而是“你要什么”：
– UNION 会自动去重 + 排序（隐式 ORDER BY），适合需要唯一结果的场景，比如合并全校学生名单；
– UNION ALL 只做拼接，不检查重复，速度通常快 2–5 倍，适合日志汇总、分表查询、兜底数据补充等明确不需要去重的场合。
字段数量和类型不匹配就会报错
这是最常卡住人的地方。MySQL 要求：所有 SELECT 语句返回的列数必须完全一致，且对应位置的列类型要兼容（比如 INT 和 BIGINT 可以，VARCHAR(10) 和 TEXT 一般也可，但 INT 和 DATETIME 就不行）。
常见错误现象：
– 报错 ERROR 1222 (21000): The used SELECT statements have a different number of columns → 列数不一致
– 报错 ERROR 1267 (HY000): Illegal mix of collations → 字符集或排序规则冲突（尤其跨库或不同表建表时编码不统一）
– 查询成功但数值被截断或转成 0 → 类型强转失败（如把字符串 'abc' 放到 INT 列位置）
实操建议：
– 写完每个 SELECT 先单独执行，确认字段数、别名、类型都对得上
– 不确定类型是否兼容时，显式用 CAST() 或 CONVERT() 统一，例如：CAST(age AS SIGNED)
– 字段名以第一个 SELECT 为准，后面语句的别名无效，别指望靠第二个 SELECT 的 AS name 改列名
ORDER BY 和 LIMIT 必须放在最后
UNION 是一个整体操作，中间的 SELECT 不能带 ORDER BY 或 LIMIT（除非用括号包成子查询）。否则会报语法错误。
正确写法只有这一种：SELECT id, name FROM t1 UNION SELECT id, name FROM t2 ORDER BY id DESC LIMIT 10;
错误写法（会报错）：SELECT id, name FROM t1 ORDER BY id UNION SELECT id, name FROM t2;
如果你真需要对某一部分先排序再合并（极少见），必须用派生表：(SELECT id, name FROM t1 ORDER BY create_time DESC LIMIT 5) UNION ALL (SELECT id, name FROM t2 ORDER BY update_time DESC LIMIT 5);
UNION ALL 在分表/补空场景中更实用
实际业务里，UNION ALL 的使用频率远高于 UNION，尤其在以下两类场景中几乎成为标配：
– 分表汇总（如按月拆分的订单表）：SELECT * FROM order_202401 UNION ALL SELECT * FROM order_202402 UNION ALL SELECT * FROM order_202403;
这里绝不能用 UNION，否则去重逻辑会误杀真实重复订单（比如用户两次下同一单号），而且性能损耗明显。
– 补充默认行（避免空结果）：SELECT user_id, SUM(amount) AS total FROM orders WHERE user_id = 123 GROUP BY user_id UNION ALL SELECT 123 AS user_id, 0 AS total FROM DUAL WHERE NOT EXISTS (SELECT 1 FROM orders WHERE user_id = 123);
注意：这里用了 DUAL（MySQL 支持），且 NOT EXISTS 必须写在第二条语句里，否则逻辑失效。
容易忽略的一点：当多个 UNION ALL 链式拼接时，MySQL 仍按从左到右顺序执行，但不会缓存中间结果；如果数据量极大，考虑加索引或改用临时表分步处理。
