优化MySQL的
UNION ALL查询性能，核心在于优化每个独立的
SELECT语句，减少数据处理量，并确保数据库配置能高效处理中间结果。这不仅仅是索引的问题，更是一种系统性的思考，如何让数据库做最少的工作，返回最精准的结果。
解决方案
要提升
UNION ALL查询的性能，我们通常需要从几个关键点入手，这就像给一辆车做全面保养，每个环节都不能掉链子。
首先，也是最基础的，是优化构成
UNION ALL的每一个
SELECT子查询。如果其中任何一个子查询本身就很慢，那么整个
UNION ALL操作都会被拖累。这意味着要为每个子查询中的
WHERE子句、
JOIN条件、
ORDER BY或
GROUP BY子句涉及的列创建合适的索引。理想情况下，如果能创建覆盖索引，让MySQL直接从索引中获取所有需要的数据，而无需回表查询，那效率会高出很多。
其次，数据传输量是另一个大头。在每个
SELECT子查询中，只选择你真正需要的列，避免使用
SELECT *。想象一下，你只是想知道每个人的名字和年龄，结果却把他们的住址、爱好、银行卡信息都拿出来，这无疑增加了数据处理和传输的负担。
再者，考虑
WHERE子句的下推。尽管MySQL优化器在某些情况下会自动将外部
WHERE条件推送到
UNION ALL的每个子查询中，但我们最好还是在每个子查询内部明确地加上这些过滤条件。这样可以确保在数据合并之前就尽可能地减少数据集大小，从而减轻后续操作的压力。
还有，对于
UNION ALL之后可能存在的
ORDER BY或
LIMIT操作，它们会显著影响性能。因为
UNION ALL会先将所有子查询的结果合并到一个临时表中，然后在这个临时表上进行排序或限制。如果这个临时表非常大，排序会消耗大量I/O和CPU资源。因此，如果业务逻辑允许，尝试在每个子查询内部进行
LIMIT操作，或者在合并结果后，确保
ORDER BY的列有合适的索引（如果可能的话，这通常比较复杂，因为是合并后的临时表）。
最后，别忘了MySQL服务器本身的配置。
tmp_table_size和
max_heap_table_size这两个参数对
UNION ALL操作中可能使用的内存临时表大小有直接影响。如果结果集太大，超出了内存限制，MySQL会把临时表写入磁盘，这会带来巨大的性能开销。适当调大这两个参数，可以减少磁盘I/O。
MySQL UNION ALL
为什么会慢？常见的性能瓶颈有哪些？
在我看来，
UNION ALL变慢，很多时候并不是
UNION ALL本身的问题，而是它所依赖的底层操作出了问题。它就像一个协调者，把多个独立任务的结果汇总起来。如果这些独立任务（也就是每个
SELECT子查询）效率低下，那么整个汇总过程自然快不起来。
常见的性能瓶颈主要有以下几点：
一个主要原因是子查询本身没有得到充分优化。如果某个
SELECT子查询在没有索引或者索引不当的列上进行过滤（
WHERE）、排序（
ORDER BY）或连接（
JOIN）操作，它就会进行全表扫描，或者使用文件排序，这会消耗大量时间。当有多个这样的慢查询组合在一起时，
UNION ALL的整体耗时就会线性增加，甚至指数级增加。
另一个不容忽视的瓶颈是数据量过大。
UNION ALL的特性是简单地将所有结果集堆叠起来，不进行去重。这意味着如果每个子查询都返回了大量行，那么最终合并的结果集会非常庞大。处理如此大的数据集，无论是内存消耗、网络传输，还是后续可能进行的排序操作，都会带来巨大的开销。
当你在
UNION ALL之后又加上了
ORDER BY或
GROUP BY子句时，临时表的创建和排序就成了性能杀手。MySQL需要将所有子查询的结果先放到一个内部的临时表中，然后才能对这个巨大的临时表进行排序或分组。如果这个临时表超出了
tmp_table_size或
max_heap_table_size的内存限制，它就会被写入磁盘，导致大量的磁盘I/O，性能急剧下降。
此外，不必要的列选择也会拖慢速度。
SELECT *是一个常见的坏习惯，它会强制数据库读取并传输所有列的数据，即使你只关心其中几列。这不仅增加了网络带宽的消耗，也增加了数据库内部处理数据的负担。
最后，MySQL服务器配置不当也可能成为瓶颈。例如，
sort_buffer_size太小可能导致排序操作频繁溢出到磁盘；
key_buffer_size或
innodb_buffer_pool_size配置不足则会影响索引和数据块的缓存效率，使得每次读取都需要从磁盘获取。
如何通过索引优化 UNION ALL
中的子查询？
优化
UNION ALL中的子查询，索引是第一道防线，也是最有效的武器。它的核心思想是让MySQL在查找数据时走“捷径”，而不是“弯路”。
关键在于，
UNION ALL本身并不会利用索引来合并结果集，索引的优化作用体现在每个独立的
SELECT子查询内部。
你需要仔细分析每个
SELECT子查询的
WHERE子句、
JOIN条件、
ORDER BY子句以及
GROUP BY子句。这些是索引发挥作用的主要场景。
WHERE
子句优化： 如果你的
WHERE条件是
column_a = 'value'或者
column_b > 100，那么在
column_a和
column_b上创建普通索引或复合索引（如果还有其他条件）是至关重要的。
EXPLAIN是你的好朋友，它会告诉你MySQL是否使用了索引，以及使用了哪种类型的索引。
-- 示例：为WHERE条件创建索引 ALTER TABLE your_table_1 ADD INDEX idx_column_a (column_a); ALTER TABLE your_table_2 ADD INDEX idx_column_b (column_b);
JOIN
条件优化： 如果子查询中包含
JOIN操作，确保
ON子句中使用的列都建立了索引。这能让MySQL快速定位到匹配的行，避免全表扫描。
-- 示例：为JOIN条件创建索引 ALTER TABLE table_a ADD INDEX idx_table_a_id (id); ALTER TABLE table_b ADD INDEX idx_table_b_a_id (a_id); -- a_id 是外键
ORDER BY
和GROUP BY
优化： 当子查询需要对结果进行排序或分组时，如果
ORDER BY或
GROUP BY的列有索引，MySQL可以利用索引的有序性来避免额外的文件排序（Using filesort），这能大幅提升性能。一个复合索引，如果其列顺序与
ORDER BY的列顺序一致，效果会非常好。
-- 示例：为ORDER BY创建索引 ALTER TABLE your_table_3 ADD INDEX idx_column_c_d (column_c, column_d);
这里需要注意的是，如果
ORDER BY和
WHERE子句同时存在，一个复合索引的列顺序需要仔细设计，通常是
WHERE条件列在前，
ORDER BY列在后。
覆盖索引（Covering Index）： 这是索引优化的“高级技巧”。如果一个索引包含了
SELECT子句中所有需要查询的列，那么MySQL就可以直接从索引中获取数据，而无需访问实际的数据行。这避免了“回表”操作，极大地减少了I/O。
-- 示例：创建覆盖索引 -- 如果你的子查询是 SELECT column_x, column_y FROM your_table WHERE column_z = 'value'; -- 那么可以创建一个复合索引 (column_z, column_x, column_y) ALTER TABLE your_table ADD INDEX idx_cover_xyz (column_z, column_x, column_y);
使用
EXPLAIN时，如果
Extra列显示
Using index，就表示使用了覆盖索引。
在实际操作中，你需要对每个子查询都运行
EXPLAIN来分析其执行计划，找出没有使用索引或者索引使用效率低下的地方，然后针对性地创建或调整索引。这是一个迭代的过程，需要不断地测试和验证。
除了索引，还有哪些高级技巧能提升 UNION ALL
效率？
除了索引这个基础且核心的优化手段，我们还有一些更“精妙”的策略来提升
UNION ALL的效率，这些方法往往需要更深入地理解业务逻辑和数据特性。
一个非常实用的技巧是精准的WHERE
子句下推与提前过滤。虽然前面提到过，但值得再次强调的是，尽可能在每个
SELECT子查询内部就应用最严格的过滤条件。这不仅仅是把外部的
WHERE条件复制进去，而是要思考，在每个子查询中，是否有一些特有的、更早就能过滤掉大量数据的条件。比如，如果你要合并不同类型商品的销售数据，每个子查询可以先通过
WHERE product_type = 'A'或
WHERE product_type = 'B'来大幅缩小数据集，而不是等
UNION ALL之后再进行筛选。这样能让数据库处理更小的数据集，减少临时表的大小和后续操作的压力。
LIMIT
的巧妙运用也是一个高级技巧。如果你最终只需要合并结果集中的前N条记录，那么
LIMIT N应该放在
UNION ALL的外部。
(SELECT col1, col2 FROM table_a WHERE condition_a) UNION ALL (SELECT col1, col2 FROM table_b WHERE condition_b) ORDER BY some_col LIMIT 100;
但如果你的业务需求是“从每个子查询中获取前M条记录，然后再合并”，那么
LIMIT M就应该放在每个子查询的内部。
(SELECT col1, col2 FROM table_a WHERE condition_a ORDER BY order_col_a LIMIT 10) UNION ALL (SELECT col1, col2 FROM table_b WHERE condition_b ORDER BY order_col_b LIMIT 10) ORDER BY some_col; -- 这里的ORDER BY和LIMIT是可选的，看是否需要对合并后的20条记录再排序或限制
这两种情况完全不同，需要根据具体需求来选择，错误的使用会导致结果不符或性能下降。
审视数据库表结构设计有时能从根本上解决问题。如果你发现自己频繁地对结构非常相似的多个表进行
UNION ALL操作，这可能是一个信号，表明你的数据库设计可能存在冗余或者不合理。例如，如果你有
orders_2022,
orders_2023这样的分年表，而大部分查询都需要跨年，那么将它们合并成一个大表
orders，并增加一个
year字段进行区分，可能会是更好的选择。当然，这需要权衡单表过大带来的管理和查询复杂性，以及分表带来的跨表查询开销。一个好的设计能让你避免很多
UNION ALL的困境。
对于极其复杂或数据量巨大的
UNION ALL操作，可以考虑使用临时表。将每个子查询的结果先存储到一个或多个临时表中，然后对这些临时表进行
UNION ALL。
CREATE TEMPORARY TABLE tmp_result_a AS SELECT col1, col2 FROM table_a WHERE condition_a; CREATE TEMPORARY TABLE tmp_result_b AS SELECT col1, col2 FROM table_b WHERE condition_b; SELECT col1, col2 FROM tmp_result_a UNION ALL SELECT col1, col2 FROM tmp_result_b;
这种方式的优点在于，可以将复杂查询分解，让MySQL的优化器有更多机会优化每一步。而且，如果对临时表进行后续操作（如
JOIN、
ORDER BY），可以为临时表创建索引，进一步提升效率。缺点是增加了I/O和存储开销，并且临时表通常只在当前会话中有效。
最后，区分UNION
和UNION ALL
。
UNION ALL的性能通常优于
UNION，因为它跳过了去重这一步。只有当你确实需要去除重复行时，才使用
UNION。如果你的业务逻辑允许重复，那么始终选择
UNION ALL。这是一个简单的选择，却能带来显著的性能差异。
这些高级技巧的运用，往往需要对业务场景有深刻的理解，并结合
EXPLAIN工具进行反复测试和验证，才能找到最适合当前情况的优化方案。
