UNION ALL 比 UNION 更快更安全，因其不去重、不排序、不建临时表；列数、顺序、类型须严格对齐；ORDER BY/LIMIT 仅能置于末尾；字段名以首SELECT为准且需显式别名。
UNION ALL 为什么比 UNION 更快更安全
因为 UNION 会强制去重 + 隐式排序，MySQL 内部要额外建临时表、扫描全结果集、排序再 dedup，大结果集下极易触发 Using temporary; Using filesort，甚至内存溢出。而 UNION ALL 就是“原样拼接”，不比较、不排序、不建临时表，执行计划干净，耗时通常只有 UNION 的 1/3～1/10。
除非你明确需要去重（比如合并两份可能含重名用户的名单），否则默认就该用 UNION ALL —— 它不是“退而求其次”，而是更贴近真实意图的正确选择。
列数、顺序、类型必须严格对齐
常见报错：ERROR 1222 (21000): The used SELECT statements have a different number of columns 或隐式转换失败导致字段值错乱（比如把 status 列的整数当成日期解析）。
- 每个
SELECT的列数量必须完全一致 - 列顺序必须一致：第一个
SELECT是id, name, created_at，后面所有都得按这个顺序，不能第二个写成name, id, created_at - 对应位置字段类型尽量相同；MySQL 允许有限隐式转换（如
TINYINT→INT、VARCHAR(10)→VARCHAR(100)），但DATE和INT、JSON和VARCHAR强行 union 很可能报错或返回NULL - 缺字段就用
NULL占位，并显式加别名统一语义，例如：SELECT id, name, NULL AS city FROM t1
ORDER BY 和 LIMIT 只能放在最后
UNION ALL 是集合操作符，不是子查询容器。中间任意一个 SELECT 单独加 ORDER BY 或 LIMIT 会直接报错：ERROR 1235 (42000): This version of MySQL doesn't yet support 'LIMIT & IN/ALL/ANY/SOME subquery'（尤其在旧版 MySQL 中）。
正确做法：
- 整体排序：把
ORDER BY放在最后一个SELECT后面，例如... UNION ALL SELECT ... ORDER BY created_at DESC - 整体分页：同理，
LIMIT 20 OFFSET 10必须写在末尾 - 某一边要取最新 5 条？必须先包成子查询：
(SELECT * FROM logs WHERE type='error' ORDER BY ts DESC LIMIT 5)，再参与UNION ALL
字段名以第一个 SELECT 为准，别名必须在这里定义
后续每个 SELECT 的列名都会被忽略。如果第一个写的是 SELECT id, name FROM users，第二个是 SELECT uid AS user_id, uname AS full_name FROM external，最终结果列名仍是 id 和 name，后者的别名无效。
所以统一命名必须在第一个 SELECT 里完成：
SELECT id AS user_id, name AS full_name, 'internal' AS source FROM users UNION ALL SELECT uid, uname, 'external' FROM external
注意：这里第二行没写别名，但字段顺序和类型必须与第一行对齐；'external' 是字符串字面量，类型自动适配为 VARCHAR，和第一行的 'internal' 兼容。
最容易被忽略的一点：当某张表字段缺失、靠 NULL 占位时，如果不给 NULL 加别名，最终列名会变成 NULL（显示为空白列头），查出来字段名不可读——务必写成 NULL AS city 这种形式。
