# MySQL UNION ALL 高效使用指南：避免去重性能损耗，查询速度提升 11 倍 > 核心要点：UNION 会触发隐式的去重和排序操作，导致全表扫描和临时表生成；而 UNION ALL 则直接合并结果集。只要业务逻辑允许重复数据存在，使用 UNION ALL 就能有效规避这些性能开销。使用时需确保列数、数据类型、别名严格对齐，ORDER BY 和 LIMIT 子句需作用于整个 UNION ALL 结果。  在业务允许重复数据或结果集本身无重复的情况下，使用 `UNION ALL` 替代 `UNION`，可以直接避免去重和隐式排序带来的性能损耗。这不仅仅是“能用即可”的选择，而是在处理百万级数据时，实现查询速度提升高达 11 倍的关键优化策略。 ## UNION 查询为何性能骤降？解读执行计划中的 Using temporary 信号 当你发现 `UNION` 查询的性能比单独执行各个子查询慢数倍时，查看 `EXPLAIN` 的输出，如果出现 `Using temporary` 和 `Using filesort`，基本可以确定原因：MySQL 正在将所有子查询的结果集存入临时表，然后进行逐行比对去重和排序。这个过程通常无法利用索引，依赖于内存或磁盘的全量扫描。 * **去重基于整行数据比对**：MySQL 的 `UNION` 去重并非依据主键或某一特定列，而是要求整行所有字段的数据类型、值（包括 NULL 值）完全一致，才被视为重复。 * **即使你只需要“手机号去重”**，`UNION` 也会将地址、创建时间等其他所有列一并纳入比对范围。 * **MySQL 8.0.19+ 版本的优化**：虽然该版本后取消了 `UNION` 的默认排序行为，但去重逻辑依然存在，`Using temporary` 的标记通常不会消失。 ## 如何正确对齐 UNION ALL 的列数、数据类型与别名以避免报错 `UNION ALL` 对结果集的结构一致性要求极为严格。常见的报错信息（例如 `ERROR 1222 (21000): The used SELECT statements have a different number of columns`）往往不会明确指出具体是哪一列出了问题，需要开发者自行逐项核对。 * **列数量必须绝对相等**：任何一个子查询的列数多一列或少一列都会直接导致语句执行失败，系统不会自动补全 `NULL` 值。 * **对应列的数据类型需兼容**：例如，`TINYINT` 和 `INT` 可以隐式转换为 `INT`。但 `VARCHAR(10)` 和 `VARCHAR(255)` 合并时，结果列会按照较长的宽度（255）定义。若后续对此列进行 `GROUP BY` 操作，可能因长度超限而导致索引失效。 * **结果集列名以第一个 `SELECT` 子句为准**：若希望统一输出列的显示名称，只能在第一个 `SELECT` 子句中使用 `AS` 定义别名。例如：`SELECT id AS user_id FROM t1 UNION ALL SELECT uid AS user_id FROM t2`。 * **处理 `TEXT` 与 `VARCHAR` 类型混用**：此类组合可能触发数据截断警告。建议提前使用 `CAST(col AS CHAR)` 进行显式的类型转换和对齐。 ## ORDER BY 与 LIMIT 子句应置于何处？为何有时会失效？ 在 `UNION ALL` 语句中，末尾的 `ORDER BY` 或 `LIMIT` 子句默认作用于整个合并后的结果集。但如果你未使用括号将整个 `UNION ALL` 包裹起来，数据库可能错误地将其解释为仅针对最后一个子查询的修饰——这在语法上是非法的。 * **正确的写法是将整个 `UNION ALL` 查询作为子查询进行包裹**： ```sql SELECT * FROM ( SELECT id, name FROM order_2025_q4 UNION ALL SELECT id, name FROM order_2026_q1 ) AS combined_orders ORDER BY id DESC LIMIT 100 ``` * **错误示例：仅在最后一个子句后添加 `ORDER BY id`**，MySQL 将报错：`This type of clause is not allowed in a UNION`。 * **大数据量场景下慎用外层 `ORDER BY`**：这会导致所有数据合并完成后才进行排序，可能生成巨大的临时表并耗尽内存。应优先考虑是否能在每个子查询内部完成排序和限制。例如，在分页场景中，可以尝试：`SELECT ... FROM t1 ORDER BY id DESC LIMIT 50 UNION ALL SELECT ... FROM t2 ORDER BY id DESC LIMIT 50`。 ## 哪些场景下必须使用 UNION，而不能图省事替换为 UNION ALL？ 切勿因 `UNION ALL` 性能更优而盲目替换。在某些业务场景下，使用 `UNION ALL` 会掩盖数据重复的问题，反而增加排查难度。 * **合并正式用户表与测试账号表**：同一个手机号可能在两个表中同时存在，业务要求最终展示的列表必须唯一 → 此时必须使用 `UNION`。 * **后续还需进行 `JOIN` 或 `GROUP BY` 操作**：如果去重逻辑本应由后续的聚合操作（例如统计各渠道的新增用户数）来完成，那么使用 `UNION ALL` 更为合理，可以避免 `UNION` 的中间排序过程干扰索引的有效使用。 * **查询不同日期的分区表**（例如 `log_20260401` 和 `log_20260402`），且表结构完全一致 → `UNION ALL` 是唯一符合逻辑的高效选择。 * **上线前务必执行 `EXPLAIN` 分析**：开发环境数据量小，性能差异不明显。但在上线前，必须通过 `EXPLAIN` 确认执行计划中没有出现 `Using temporary`。如果出现，需立即定位是 `UNION` 操作还是查询的其他部分导致了性能瓶颈。 最容易被忽视的一点是：**字段类型隐式转换所引发的索引失效风险，其隐蔽性甚至超过直接的性能损耗**。例如，一个子查询使用 `VARCHAR(16)`，另一个使用 `CHAR(8)`，`UNION ALL` 后该列的实际类型可能变为 `VARCHAR(16)`，但查询优化器可能误判其选择性，导致本该使用索引的 `WHERE` 条件退化为全表扫描。