GaussDB中UNION结果顺序问题解析与优化实践

1. 问题背景：为什么UNION结果顺序值得关注

在GaussDB数据库的实际应用中，UNION操作的结果顺序问题经常成为开发者的困惑点。上周我在处理一个报表合并需求时，就遇到了UNION结果顺序不符合预期的情况——原本应该按时间排序的日志记录，在UNION后出现了乱序，直接影响了前端展示效果。

这个问题看似简单，但背后涉及数据库查询优化器的执行机制。与MySQL、Oracle等传统数据库不同，GaussDB作为华为开源的分布式数据库，其UNION实现有独特的考虑因素。特别是在处理海量数据时，结果顺序的不确定性可能导致业务逻辑错误。

2. UNION操作的基础原理与GaussDB实现

2.1 标准SQL中的UNION语义

按照SQL标准定义，UNION用于合并两个或多个SELECT语句的结果集，并自动去除重复行。其基本语法为：

sql复制SELECT column1, column2 FROM table1
UNION
SELECT column1, column2 FROM table2

关键特性包括：

• 结果集列数必须相同
• 对应列的数据类型必须兼容
• 默认会消除重复行（使用UNION ALL可保留重复项）

2.2 GaussDB的UNION实现特点

GaussDB在实现UNION操作时，会根据查询复杂度自动选择以下两种执行计划之一：

1. Hash Aggregate方案：

   • 对每个子查询结果计算哈希值
   • 通过哈希表快速去重
   • 典型场景：子查询结果量大且重复率高

2. Sort-Merge方案：

   • 先对各子查询结果排序
   • 然后合并有序结果集
   • 典型场景：子查询已带ORDER BY或需要保序

通过EXPLAIN命令可以看到实际采用的执行计划：

sql复制EXPLAIN 
SELECT id FROM users WHERE status=1
UNION
SELECT id FROM orders WHERE amount>100;

3. 影响UNION结果顺序的关键因素

3.1 执行计划的选择

如2.2节所述，不同的执行计划会导致结果顺序的差异：

• Hash方案：结果顺序取决于哈希函数和存储分布
• Sort-Merge方案：结果通常按排序列有序

3.2 分布式架构的影响

GaussDB作为分布式数据库，数据可能分散在多个DN节点上。UNION操作会经历以下过程：

1. 各DN并行执行子查询
2. CN节点收集部分结果
3. 在协调节点完成最终合并

这个过程中，网络传输、数据分片都会影响结果的最终顺序。

3.3 隐式排序的不确定性

即使子查询包含ORDER BY，如：

sql复制(SELECT id FROM t1 ORDER BY create_time)
UNION
(SELECT id FROM t2 ORDER BY create_time)

标准SQL并不保证UNION后的整体顺序。GaussDB可能会在合并阶段重新排列结果。

4. 控制UNION结果顺序的实践方案

4.1 外层显式排序（推荐）

最可靠的方式是在UNION外部添加ORDER BY：

sql复制SELECT id, create_time FROM (
    SELECT id, create_time FROM log_202301
    UNION ALL
    SELECT id, create_time FROM log_202302
) AS combined_logs
ORDER BY create_time DESC;

注意：对于大表UNION，建议在排序字段上建立索引，否则可能引起性能问题。

4.2 使用辅助排序列

当需要保持各子查询的内部顺序时，可以添加序列号：

sql复制SELECT id FROM (
    SELECT id, 1 AS source, ROW_NUMBER() OVER() AS rn FROM t1
    UNION ALL
    SELECT id, 2 AS source, ROW_NUMBER() OVER() AS rn FROM t2
) ORDER BY source, rn;

4.3 临时表方案

对于复杂场景，可先存入临时表再排序：

sql复制CREATE TEMP TABLE temp_result AS
SELECT id, create_time, 'log1' AS src FROM log1
UNION ALL
SELECT id, create_time, 'log2' AS src FROM log2;

-- 然后对临时表进行排序操作
SELECT * FROM temp_result ORDER BY create_time;

5. 性能优化与避坑指南

5.1 索引设计策略

针对UNION+ORDER BY场景，建议：

1. 为排序字段建立复合索引
2. 考虑使用局部索引（Partial Index）：

   sql复制CREATE INDEX idx_log1_time ON log1(create_time) WHERE status=1;
   

5.2 分页查询的陷阱

直接分页UNION结果可能导致逻辑错误：

sql复制-- 错误示例（可能丢失数据）
SELECT * FROM (
    SELECT id FROM t1
    UNION
    SELECT id FROM t2
) LIMIT 10 OFFSET 20;

正确做法是先完整排序再分页：

sql复制WITH combined AS (
    SELECT id, 1 AS source FROM t1
    UNION ALL
    SELECT id, 2 AS source FROM t2
    ORDER BY id  -- 关键排序
)
SELECT * FROM combined LIMIT 10 OFFSET 20;

5.3 内存与work_mem参数

大结果集排序可能消耗大量内存，需合理设置：

sql复制SET work_mem='64MB';  -- 根据实际情况调整

可通过以下SQL监控排序内存使用：

sql复制SELECT * FROM pg_stat_activity 
WHERE query LIKE '%UNION%' ORDER BY backend_start DESC;

6. 特殊场景：UNION ALL与按位UNION

6.1 UNION ALL的性能优势

当确定结果无重复时，使用UNION ALL可避免去重开销：

sql复制-- 效率比UNION高约30%（实测数据）
SELECT id FROM active_users
UNION ALL
SELECT id FROM vip_users;

6.2 按位UNION的实现

虽然GaussDB不直接支持按位UNION，但可通过位运算模拟：

sql复制SELECT BIT_OR(flag) FROM (
    SELECT 1<<3 AS flag FROM t1 WHERE condition1
    UNION ALL
    SELECT 1<<5 AS flag FROM t2 WHERE condition2
);

这种技巧常用于权限合并等场景。

7. 真实案例：电商订单合并查询优化

最近优化过一个电商平台的订单查询接口，原始SQL如下：

sql复制SELECT order_id FROM unpaid_orders
UNION
SELECT order_id FROM paid_orders
ORDER BY create_time;

问题现象：当订单量超过10万时，查询耗时超过8秒。

优化方案：

1. 改用UNION ALL（经业务确认无重复订单）
2. 为create_time列添加分区索引
3. 使用并行查询提示

最终SQL：

sql复制SELECT /*+ PARALLEL(4) */ order_id FROM (
    SELECT order_id, create_time FROM unpaid_orders
    UNION ALL
    SELECT order_id, create_time FROM paid_orders
) ORDER BY create_time LIMIT 1000;

优化后性能提升5倍以上，响应时间稳定在1.5秒内。