UNIONvsUNION ALL：核心差异一览
|------------|-----------------------------------------------------------|-------------------------------------------------------|
| 对比维度 | UNION | UNION ALL |
| 核心行为 | 合并 + 去重 ：返回所有结果集的并集，并去除重复的行。其效果等同于UNION DISTINCT。 | 直接合并 ：简单地将多个结果集拼接在一起，保留所有行，包括重复的行。 |
| 性能表现 | 较慢：需要执行额外的排序和去重操作，会消耗大量CPU、内存和I/O资源。 | 较快：仅做简单的数据合并，处理逻辑简单，资源消耗低。 |
| 典型应用场景 | 当业务逻辑必须消除重复数据时使用，例如合并来自不同系统的、可能存在重复的客户主数据。 | 当不需要去重 ，或能确信各子查询结果集之间没有重复时使用，例如合并不同时间段的分区日志表。 |
为什么UNION会很慢？
UNION的性能瓶颈主要来自于其背后的**排序-去重（Sort-Distinct）**机制。数据库在处理UNION时，实际执行的是类似SELECT DISTINCT * FROM (...子查询的UNION ALL...)的操作。这个过程会带来巨大的额外开销：
- 创建临时表：数据库需要创建一个临时的内存或磁盘表来存储UNION ALL后的全部中间结果集。如果数据量很大，内存无法容纳，就会产生磁盘I/O，极大地拖慢速度。
- 排序操作 ：为了高效地找出重复行，数据库通常会对临时表中的数据进行排序。这是一个**O(n log n)**复杂度的操作，数据量越大，排序消耗的时间呈非线性增长。
- 去重比较：在排序后的结果集上进行逐行比较，以过滤掉重复行。这会消耗额外的CPU资源。
- 潜在索引失效：为了进行全排序，数据库很可能无法有效利用原有表上的索引，导致查询性能进一步下降。
这些额外的操作，使得UNION的性能开销远高于UNION ALL。一个基准测试显示，在处理百万行级别的数据时，UNION的耗时可能是UNION ALL的10倍以上。
核心优化建议与最佳实践
基于以上分析，针对GBase 8a的UNION查询，核心优化原则非常明确：
- 首要原则：能用UNION ALL就绝不用UNION
GBase 8a官方的最佳实践文档明确指出："能用union all尽量不用union"。在开发SQL时，除非业务上有明确的"去重"要求，否则应始终优先使用UNION ALL。
- 如果必须去重，如何优化？
- 先合并后去重：如果必须消除重复行，可以先用UNION ALL合并，再在外层用SELECT DISTINCT ...进行去重。这种方式给了优化器更多选择，有时可能比直接使用UNION更高效。
- 明确数据无重复 ：如果通过业务逻辑或数据特征（如使用INSERT时已保证数据不重复），能确保各子查询间没有重复数据，那么直接使用UNION ALL是完全安全的，避免了不必要的性能开销。
- 利用索引加速：当必须使用UNION时，为子查询中涉及的过滤和排序列创建合适的覆盖索引，可以帮助减少磁盘I/O，提升排序和去重的效率。
- 针对GBase 8a的进阶优化
- GBase 8a提供了一个性能优化开关，可以尝试改善UNION类算子的执行效率。_gbase_one_pass_union参数：这是一个关于Union类算子优化的开关参数。在GBase 8a的单机模式下，可以尝试设置_gbase_one_pass_union=1来启用此优化，这可能会改变UNION的执行策略，从而提升性能。该参数默认是关闭的（_gbase_one_pass_union=0）。