UNION ALL本身性能开销几乎为零，真正拖慢查询的是未优化的子查询：需对每个子查询单独EXPLAIN验证索引命中、避免SELECT *、显式下推WHERE条件、合理使用LIMIT、注意类型隐式转换及COLLATION统一。
UNION ALL子查询本身不慢，慢的是没优化的子查询
UNION ALL只是把结果堆起来，不排序也不去重，性能开销几乎为零。真正拖慢整个查询的，是它包裹的每个SELECT子句——如果其中某个子查询全表扫描、没走索引、或返回了几百万行再合并，那UNION ALL就成了“背锅侠”。你看到执行计划里Using temporary; Using filesort出现在最后一步，大概率不是UNION ALL的问题，而是某个子查询输出太大，导致后续ORDER BY或LIMIT被迫在临时表上操作。
实操建议：
- 对每个子查询单独跑
EXPLAIN，确认是否命中索引、是否回表、是否用到覆盖索引 - 避免在子查询中写
SELECT *，只取业务真正需要的列，减少I/O和内存占用 - 如果子查询带
WHERE条件，不要依赖优化器自动下推——显式写在每个子查询内部，比如SELECT id, name FROM t1 WHERE status = 'active' UNION ALL SELECT id, name FROM t2 WHERE status = 'active' - 注意MySQL 8.0+对
UNION ALL子查询的物化行为：若子查询结果集大且后续要JOIN或GROUP BY，引擎可能主动物化，这时tmp_table_size和max_heap_table_size配置就关键了
ORDER BY和LIMIT必须放在UNION ALL最外层，但别盲目加
语法强制要求ORDER BY只能写在最后一个SELECT之后，LIMIT同理。但这不等于你应该无脑加。很多人为了“看着整齐”在UNION ALL末尾加ORDER BY created_at DESC LIMIT 100，结果发现查询从200ms飙到8秒——因为数据库得先把所有子查询结果全拉出来，再排序取前100。
实操建议：
- 如果业务只要最新100条，优先考虑在每个子查询里加
LIMIT（需确认语义是否等价），例如：(SELECT * FROM jan_orders ORDER BY created_at DESC LIMIT 100) UNION ALL (SELECT * FROM feb_orders ORDER BY created_at DESC LIMIT 100)，再在外层ORDER BY created_at DESC LIMIT 100 - 外层
ORDER BY的列，必须是第一个SELECT中出现的列名（不是别名），否则报错Unknown column 'xxx' in 'order clause' - 若外层要按非首查列排序，必须用子查询包装：
SELECT * FROM (SELECT a,b,c FROM t1 UNION ALL SELECT a,b,c FROM t2) AS u ORDER BY b
类型隐式转换会让UNION ALL悄悄变慢甚至报错
两个子查询对应位置的列类型不一致时，MySQL会尝试隐式转换，比如把VARCHAR(50)和TEXT都转成TEXT，或者把INT和DECIMAL(10,2)统一成DECIMAL。这看起来“能跑通”，但实际代价很大：转换过程消耗CPU，更严重的是，转换后字段无法使用原有索引，还可能触发Illegal mix of collations错误。
实操建议：
- 用
SHOW CREATE TABLE核对各源表对应字段的实际类型和字符集，尤其是CHARSET和COLLATE - 显式用
CAST()或CONVERT()对齐类型，例如：SELECT CAST(order_id AS UNSIGNED) AS order_id FROM t1 UNION ALL SELECT CAST(id AS UNSIGNED) AS order_id FROM t2 - 字符串字段务必统一
COLLATION，比如都用utf8mb4_0900_as_cs，避免UNION时报Illegal mix of collations for operation 'union'
WITH + UNION ALL组合比嵌套子查询更可控
当多个子查询逻辑复杂、有复用需求，或需要中间结果过滤时，硬写一堆UNION ALL子查询容易失控。比如要合并三个月订单，还要分别排除测试数据、打标渠道来源——这时用WITH定义CTE，再UNION ALL拼接，可读性和维护性高得多，MySQL 8.0+还能内联优化，不一定物化。
实操建议：
- 把公共过滤逻辑抽到CTE里，例如：
WITH clean_orders AS (SELECT * FROM raw_orders WHERE is_test = 0 AND channel IS NOT NULL) SELECT * FROM clean_orders WHERE month = '2026-07' UNION ALL SELECT * FROM clean_orders WHERE month = '2026-08' - 避免CTE嵌套过深，尤其不要在CTE里再套
UNION ALL，MySQL 5.7不支持，8.0+虽支持但调试困难 - PostgreSQL用户注意：
WITH默认是优化屏障（强制物化），如需内联，得加MATERIALIZED或NOT MATERIALIZED提示（PG 12+）
最常被忽略的一点：UNION ALL的“零开销”只存在于理想路径。一旦某个子查询因类型转换丢失索引、或因未下推WHERE返回海量中间结果，整个查询的瓶颈就从“合并”转移到了“生产”。盯住每个SELECT的EXPLAIN输出，而不是只看UNION ALL那一行。
