深度解析SQL视图中UNION ALL比UNION执行效率高的本质原因

先说几个核心结论：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”这个选择题，而是理解数据库底层到底做了什么、跳过了什么，以及这些差异在日常开发中如何累积成压倒性的性能鸿沟。