UNION ALL比UNION快的根本原因是跳过去重+排序链路，纯流式拼接零临时表、零文件排序；UNION强制触发DISTINCT+ORDER BY，需临时结构、哈希/排序及可能磁盘I/O，100万行时慢11倍以上。
UNION ALL 在 SQL 视图中比 UNION 快，根本原因不是“少做了一步去重”，而是它跳过了整个去重+排序的数据处理链路——数据库压根不启动那套机制。
UNION 实际触发的是 DISTINCT + ORDER BY 两层开销
-
UNION不是“先拼再筛”，而是强制走一套集合归并流程：所有子查询结果必须先写入临时结构（内存或磁盘），再做哈希/排序去重，最后按第一列升序输出（即使你没写ORDER BY） - 执行计划里常出现
Using temporary和Using filesort，尤其当参与列无索引、数据量超 5 万行时，I/O 和 CPU 成为瓶颈 - 即使你在外层加了
ORDER BY id，数据库仍可能执行两次排序：一次为去重，一次为你显式指定的顺序
UNION ALL 是纯流式拼接，零中间态
- 它不做任何行级比较，不申请额外内存建哈希表，不写临时文件，也不调整顺序
- 第一个
SELECT开始返回数据，第二个紧接着追加，全程保持 pipeline 模式 - EXPLAIN 看不到
Using temporary或Using filesort，执行计划干净利落 - 对于分表查询（如
log_202604和log_202605）、状态互斥查询（如status = 1和status = 2），UNION ALL的语义更准确、性能更可预期
列对齐和类型兼容性，两者要求完全一致
-
UNION ALL并不宽容：列数不等、类型不兼容（比如INT和JSON）、NULL 性约束冲突（NOT NULL vs NULLable），一样报错 - 别指望用
UNION ALL绕过类型检查——MySQL 8.0+ 在严格模式下，第一条 SELECT 返回NOT NULL VARCHAR(50)，第二条返回NULL，直接拒绝执行 - 列名永远以第一个
SELECT为准，后续子查询中的别名（如SELECT id AS uid）无效
外层 ORDER BY 是唯一可控排序方式
- 子查询里写
ORDER BY没用，语法允许但被忽略；UNION的隐式排序规则不可靠（可能按主键、也可能按表达式推导出的列），UNION ALL更是完全依赖执行顺序 - 正确写法只有一种：
SELECT id, name FROM users_2023<br>UNION ALL<br>SELECT id, name FROM users_2024<br>ORDER BY id;
- 少了这句，结果顺序在不同 MySQL 版本、不同执行路径下都可能变化，上线后容易引发前端渲染错乱或分页错位
真正容易被忽略的，是 UNION 的性能衰减是非线性的——100 万行时慢 11 倍，而嵌套在视图里再套一层 LIMIT OFFSET，代价可能翻倍还不止。
