MySQL联合查询全解析：从基础到实战应用

一、联合查询的核心概念与适用场景

MySQL联合查询（UNION）是数据库操作中用于合并两个或多个SELECT语句结果集的核心技术，其核心价值在于打破单表查询限制，实现跨表数据整合。与JOIN操作不同，UNION通过垂直堆叠结果集实现数据合并，而非横向关联字段。这种特性使其在以下场景中具有不可替代性：

1. 数据整合需求：当需要合并来自不同表但结构相似的数据时（如合并不同季度的销售数据），UNION可避免复杂JOIN操作带来的性能损耗。
2. 去重与统计：通过UNION ALL保留重复行，UNION DISTINCT（默认）自动去重，为统计报表提供灵活的数据处理方式。
3. 子查询优化：在复杂查询中，UNION可将大查询拆分为多个小查询，通过中间结果合并提升执行效率。

典型案例：某电商平台需统计全国各仓库的库存总量，但库存数据分散在region_east、region_west等按区域划分的表中。使用UNION可快速合并所有区域库存，避免编写冗长的CASE WHEN语句。

二、联合查询的语法结构与关键规则

2.1 基础语法

SELECT column1, column2 FROM table1
UNION [ALL]
SELECT column1, column2 FROM table2;

关键规则：

• 列数与类型匹配：所有SELECT语句必须返回相同数量的列，且对应列的数据类型需兼容（如VARCHAR与INT混合可能导致隐式转换）。
• 列名取自第一个SELECT：结果集的列名由首个SELECT语句决定，后续语句的列名被忽略。
• ORDER BY与LIMIT：全局排序需在最后一个SELECT后添加，且只能引用第一个SELECT的列名或位置序号。

2.2 高级用法

1. 多表联合：可串联多个SELECT，但需确保每步合并都符合类型匹配规则。

   SELECT name FROM users
   UNION
   SELECT product_name FROM products
   UNION
   SELECT category FROM categories;

2. 混合UNION与JOIN：在复杂查询中，可先通过JOIN生成中间表，再用UNION合并结果。

   SELECT u.name, o.order_date FROM users u
   JOIN orders o ON u.id = o.user_id
   UNION
   SELECT g.guest_name, o.order_date FROM guests g
   JOIN orders o ON g.id = o.guest_id;

三、性能优化与最佳实践

3.1 性能瓶颈分析

联合查询的性能风险主要来自：

• 全表扫描：未加WHERE条件的UNION可能导致扫描所有表数据。
• 临时表创建：MySQL需创建临时表存储中间结果，大数据量时易引发磁盘I/O压力。
• 排序开销：UNION后的ORDER BY需对合并后的数据重新排序。

3.2 优化策略

1. 添加索引：确保WHERE、JOIN和ORDER BY涉及的列有索引。

   -- 为高频查询条件创建复合索引
   ALTER TABLE orders ADD INDEX idx_user_date (user_id, order_date);

2. 限制数据量：在每个SELECT后添加LIMIT减少中间结果。

   (SELECT * FROM logs_2023 WHERE type='error' LIMIT 1000)
   UNION
   (SELECT * FROM logs_2024 WHERE type='error' LIMIT 1000);

3. 使用UNION ALL替代UNION：当确定无需去重时，UNION ALL可跳过排序去重步骤，性能提升达30%-50%。

四、实战案例解析

案例1：跨表数据合并

需求：合并active_users和inactive_users表，统计所有用户状态分布。

SELECT user_id, 'active' AS status FROM active_users
UNION
SELECT user_id, 'inactive' AS status FROM inactive_users;

优化点：通过添加状态标签列，使结果集更具可读性，同时避免复杂CASE表达式。

案例2：分页查询优化

需求：从多个数据源分页获取最新10条记录。

(SELECT * FROM news WHERE source='A' ORDER BY publish_date DESC LIMIT 10)
UNION
(SELECT * FROM news WHERE source='B' ORDER BY publish_date DESC LIMIT 10)
ORDER BY publish_date DESC LIMIT 10;

注意事项：此写法可能导致分页不准确，更优方案是先合并所有数据再分页。

五、常见错误与解决方案

1. 列数不匹配：

   -- 错误示例：列数不一致
   SELECT id, name FROM users
   UNION
   SELECT id FROM products;  -- 缺少name列

   修复：补充NULL占位列保持结构一致。

   SELECT id, name FROM users
   UNION
   SELECT id, NULL AS name FROM products;

2. 数据类型冲突：

   -- 错误示例：VARCHAR与INT混合
   SELECT product_code FROM products
   UNION
   SELECT stock_quantity FROM inventory;  -- 字符串与数字混合

   修复：使用CAST显式转换类型。

   SELECT CAST(product_code AS CHAR) FROM products
   UNION
   SELECT CAST(stock_quantity AS CHAR) FROM inventory;

六、联合查询的替代方案对比

方案	适用场景	性能特点
UNION	结构相似数据的合并	中等，需创建临时表
JOIN	关联数据的横向扩展	高，利用索引直接关联
子查询	嵌套条件查询	低，可能产生多次扫描
临时表	复杂查询的中间结果存储	高，但需额外维护

选择建议：当需合并结构相似但无直接关联的数据时，UNION是最佳选择；若存在关联关系，优先使用JOIN。

七、进阶技巧：联合查询与存储过程结合

通过存储过程封装联合查询，可实现动态数据合并：

DELIMITER //
CREATE PROCEDURE merge_sales_data(IN region VARCHAR(20))
BEGIN
  SET @sql = CONCAT('
    SELECT product_id, SUM(quantity) AS total FROM sales_', region, '
    UNION
    SELECT product_id, SUM(quantity) FROM sales_national
    GROUP BY product_id');
  PREPARE stmt FROM @sql;
  EXECUTE stmt;
  DEALLOCATE PREPARE stmt;
END //
DELIMITER ;

此方案通过动态SQL生成区域销售与全国销售的合并报表，显著提升灵活性。

总结

MySQL联合查询是处理多源数据整合的利器，其核心价值在于通过结构化合并实现数据的高效整合。开发者需掌握其语法规则、性能优化技巧及适用场景，避免因误用导致性能问题。在实际应用中，建议遵循”先过滤、再合并、后排序”的原则，结合索引优化和UNION ALL策略，可显著提升查询效率。对于复杂场景，可考虑与存储过程、临时表等技术结合，构建更灵活的数据处理方案。