SQL联合查询(UNION)原理、优化与实战应用

1. 联合查询的本质与适用场景

联合查询（UNION）是SQL中用于合并多个SELECT语句结果集的操作符。我第一次接触这个概念是在处理电商平台的订单报表时——需要将来自不同地区的订单数据合并统计。与简单的单表查询不同，联合查询的核心价值在于它能垂直整合数据结构相同但来源不同的数据集。

实际工作中常见的适用场景包括：

• 合并多张结构相同的历史数据表（如按月分表的用户行为日志）
• 集成来自不同业务系统的同类型数据（如ERP和CRM系统中的客户信息）
• 实现分库分表架构下的跨节点数据聚合
• 构造包含多种统计维度的综合报表

关键特性：参与UNION的各个查询必须具有相同数量的列，且对应列的数据类型必须兼容。MySQL会默认去除重复行，使用UNION ALL可保留全部记录。

2. 基础语法与执行逻辑解析

2.1 标准语法结构

sql复制SELECT column1, column2 FROM table1
UNION [ALL]
SELECT column1, column2 FROM table2
[ORDER BY clause]
[LIMIT clause];

2.2 执行过程拆解

1. 独立执行：先分别执行所有UNION连接的SELECT语句
2. 结果合并：将各语句结果集合并到临时表
3. 去重处理：默认对临时表执行DISTINCT操作（除非使用UNION ALL）
4. 最终排序：如有ORDER BY则对合并后结果排序
5. 限制输出：最后应用LIMIT条件

性能提示：UNION操作会产生临时表，当处理大数据量时可能消耗大量内存。我曾在一个千万级数据量的报表查询中，因为忘记加LIMIT导致服务器内存爆满。

3. 高级应用与优化策略

3.1 类型转换处理

当对应列数据类型不一致时，MySQL会按以下优先级进行隐式转换：

code复制DATETIME > TIMESTAMP > DATE
DECIMAL > DOUBLE > FLOAT
BIGINT > INT > MEDIUMINT > SMALLINT > TINYINT

实际案例：合并用户表和员工表的手机号字段时，如果一个是VARCHAR(11)另一个是CHAR(11)，虽然显示长度相同，但底层处理方式不同可能导致性能差异。

3.2 排序与分页技巧

• 全局排序：ORDER BY必须写在最后一个SELECT之后
• 局部排序：如需对单个结果集排序，需使用派生表：

sql复制(SELECT id, name FROM users ORDER BY id DESC LIMIT 10)
UNION
(SELECT id, name FROM employees ORDER BY salary LIMIT 5)
ORDER BY name;

3.3 性能优化方案

1. 索引利用：确保每个SELECT语句都能利用到合适的索引
2. 列裁剪：只SELECT必要的列，避免传输冗余数据
3. WHERE前置：在每个SELECT中先过滤再联合
4. UNION ALL优先：确定无需去重时使用ALL可节省30%+资源

4. 实战问题排查手册

4.1 常见错误代码

4.2 隐式坑点记录

1. 列名继承问题：结果集列名默认采用第一个SELECT的列名
2. LIMIT作用域：单独SELECT中的LIMIT可能被优化器忽略
3. 事务一致性：跨库UNION时可能遇到事务隔离问题

5. 典型业务场景实现

5.1 跨年销售报表合并

sql复制-- 2022年数据（InnoDB表）
SELECT product_id, SUM(amount) AS total 
FROM sales_2022 
WHERE status = 'completed'
GROUP BY product_id

UNION ALL

-- 2023年数据（MyISAM表）
SELECT goods_id AS product_id, SUM(quantity) AS total
FROM orders_2023
WHERE pay_status = 1
GROUP BY goods_id

ORDER BY total DESC
LIMIT 100;

5.2 多平台用户集成

sql复制-- 主站用户（带手机号）
SELECT user_id, mobile, 'web' AS source
FROM web_users
WHERE reg_time > '2023-01-01'

UNION

-- APP用户（带设备号）
SELECT uid AS user_id, device_id AS mobile, 'app' AS source  
FROM app_users
WHERE last_login > UNIX_TIMESTAMP('2023-01-01')

-- 结果可用于统一用户画像分析

6. 衍生技术对比

6.1 UNION vs JOIN

6.2 UNION vs 应用层合并

对于需要后处理的场景，有时在程序代码中合并结果集更高效：

• 当各数据源来自不同数据库时
• 需要复杂的分组计算时
• 结果集需要差异化处理时

7. 特殊类型处理经验

7.1 JSON字段合并

MySQL 8.0+支持JSON类型的UNION操作，但要注意：

sql复制-- 正确做法：保持JSON结构一致
SELECT id, JSON_OBJECT('name', name) AS info FROM table1
UNION
SELECT id, JSON_OBJECT('name', title) AS info FROM table2

-- 错误示例：结构不一致会导致类型转换异常
SELECT id, JSON_ARRAY(name) FROM table1
UNION
SELECT id, JSON_OBJECT('n', name) FROM table2

7.2 二进制数据注意事项

BLOB/TEXT类型参与UNION时：

1. 比较时只使用前1024字节
2. 结果集以第一个SELECT的max_length为准
3. 大字段建议改用程序层处理

8. 分布式环境下的实践

在分库分表架构中，UNION常用于实现：

1. 跨分片查询：合并多个数据节点的结果
2. 异构数据源整合：合并MySQL和Elasticsearch的查询结果
3. 读写分离扩展：合并主库和从库的统计结果

典型ShardingSphere配置示例：

yaml复制# 在分片配置中定义UNION路由
spring:
  shardingsphere:
    rules:
      sharding:
        binding-tables:
          - t_order_2022,t_order_2023
        tables:
          t_order:
            actual-data-nodes: ds.t_order_$->{2022..2023}

9. 监控与性能分析

9.1 EXPLAIN解析要点

分析UNION查询的执行计划时重点关注：

1. 临时表标记：出现"Using temporary"表示创建了临时表
2. 文件排序："Using filesort"说明有磁盘排序
3. 子查询数量：每个SELECT对应一个独立的id值

9.2 慢查询优化案例

某次优化经历：一个包含5个UNION的报表查询耗时8秒，通过以下调整降至1.2秒：

1. 将OR条件改写为UNION ALL（利用不同索引）
2. 为每个SELECT单独添加WHERE条件过滤
3. 使用覆盖索引避免回表

优化前后对比：

sql复制-- 优化前（全表扫描）
SELECT * FROM logs WHERE type=1 OR type=2

-- 优化后（索引扫描）
SELECT * FROM logs WHERE type=1
UNION ALL
SELECT * FROM logs WHERE type=2

10. 版本特性差异

10.1 MySQL各版本改进

10.2 与其他数据库对比

1. PostgreSQL：支持UNION/INTERSECT/EXCEPT全套操作
2. Oracle：提供特殊的UNION ALL PUSHED PREDICATE优化
3. SQL Server：支持TOP子句与UNION组合使用

11. 最佳实践总结

1. 设计原则：

   • 优先考虑UNION ALL除非确实需要去重
   • 保持各SELECT语句的列结构严格一致
   • 为排序字段建立合适的索引

2. 避坑指南：

   • 避免在大结果集上使用ORDER BY + LIMIT
   • 处理TEXT/BLOB类型时要特别注意长度限制
   • 分布式环境下注意事务一致性边界

3. 调试技巧：

   • 用EXPLAIN分析每个SELECT的执行计划
   • 通过分段执行定位性能瓶颈
   • 使用SQL_NO_CACHE测试真实性能

在实际项目中，我发现合理使用UNION可以大幅简化很多复杂的数据整合场景。特别是在处理历史数据迁移时，通过UNION实现新旧系统的数据并行查询，为迁移验证提供了极大便利。一个实用的建议是：对于频繁执行的UNION查询，考虑将其物化为视图或定期生成的中间表。