先说几个核心结论：UNION ALL 比 UNION 性能更优，根本原因并非“少做了一个去重操作”，而是它直接跳过了完整的数据去重与排序处理链路——数据库引擎根本不会启动那套机制。换句话说，前者走的是全流程，后者则走捷径直达，最终性能差异自然天壤之别。
在 100 万行级数据量下，慢 11 倍仅仅是起步价。如果嵌套在视图后再套一层 LIMIT OFFSET，性能衰减甚至翻倍以上。更值得关注的是，许多开发者并不清楚这种性能瓶颈究竟源自何处，这恰恰是 SQL 查询优化中容易被忽略的环节。
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并不比UNION更“好说话”：列数不相等、类型不兼容（例如INT与JSON）、NULL 性约束冲突（NOT NULL 与 NULLable），它同样会直接报错。别期望用UNION ALL绕过类型检查，这仍是常见误解。- 一个典型的例子：MySQL 8.0+ 在严格模式下，如果第一条
SELECT返回NOT NULL VARCHAR(50)，第二条却返回NULL，它会拒绝执行，不给任何通融余地。 - 列名始终以第一个
SELECT为准——后续子查询中的别名（比如SELECT id AS uid）是无效的。这条规则在实际开发中曾引发过不少令人困惑的 bug，值得格外留意。
外层 ORDER BY 才是唯一可控的排序方式
- 子查询里写
ORDER BY基本是徒劳——语法上允许，但实际会被忽略。UNION的隐式排序规则不可靠（可能按主键，也可能按表达式推导出的列），UNION ALL更是完全依赖执行顺序。 - 正确的写法只有一种：
SELECT id, name FROM users_2023 UNION ALL SELECT id, name FROM users_2024 ORDER BY id;
- 缺少这句
ORDER BY，结果顺序在不同 MySQL 版本、不同执行路径下都可能变化。一旦上线后前端渲染错乱或分页错位，排查成本极高——因为问题并非每次都出现，而是带有随机性，极易被忽略。
归根结底，UNION 的性能衰减是非线性的。100 万行时慢 11 倍，嵌套在视图里再加一层 LIMIT OFFSET，代价可能翻倍还不止。真正值得关注的不是“多用 UNION ALL 还是 UNION”这个选择题，而是理解数据库底层到底做了什么、跳过了什么，以及这些差异在日常开发中如何累积成压倒性的性能鸿沟。
