PHP使用union合并查询结果详解

本文深入解析了PHP中使用MySQL UNION合并查询结果的核心要点与实战陷阱：从UNION严格的字段数一致、类型兼容及列名继承规则，到UNION（去重）与UNION ALL（高效无去重）的性能权衡；重点揭示PHP层三大易错细节——子查询必须括号包裹、PDO参数需独立绑定、字符集不一致须显式转换；并理性指出：当逻辑复杂、结构难对齐或数据量适中时，用PHP数组合并（如array_merge）、分查统计、字段映射等方案反而更清晰、可控且不易出错——真正影响效率的往往不是SQL语法本身，而是脱离实际场景的“数据库优先”思维定式。

MySQL 中 UNION 合并两个查询结果的硬性前提

必须字段数一致、对应位置的数据类型尽量兼容，否则直接报错。不是“把两堆数据随便拼一起”，而是像拉链一样对齐列。

• SELECT id, name FROM users 和 SELECT id, title FROM posts 可以 UNION（都是两列，id 对 id，name/title 都是字符串）
• SELECT id, name FROM users 和 SELECT created_at FROM logs 不行（列数不同，类型也错位）
• 列名以第一个 SELECT 为准，后面查询的列名会被忽略——别指望用第二个查询的 AS 改最终字段名

UNION vs UNION ALL：去重开销你真需要吗？

默认 UNION 会自动去重，相当于加了 DISTINCT；UNION ALL 不检查重复，速度更快，内存更省。

• 如果你确定两个结果集无交集（比如查 status = 'active' 和 status = 'archived'），直接用 UNION ALL
• 如果其中任一查询本身可能含重复行（例如关联了多对一表但没 GROUP BY），UNION 会帮你兜底，但代价是临时排序+去重
• 在大表上执行时，UNION 可能触发 Using temporary; Using filesort，看 EXPLAIN 能确认

PHP 中拼接 UNION 查询要注意的三处陷阱

不是写完 SQL 往 mysqli_query() 或 PDO ->query() 里一扔就完事，PHP 层容易漏掉关键控制点。

• 每个子查询必须用括号包裹再组合，尤其带 ORDER BY 或 LIMIT 时：(SELECT ... ORDER BY id LIMIT 10) UNION (SELECT ... ORDER BY id LIMIT 10) —— 外层 ORDER BY 才有效
• PDO 预处理不能跨子查询绑定参数，UNION 的两个 SELECT 里都要单独占位符，不能共用 :user_id 名字（除非用命名参数并确保两次绑定同一值）
• 字符集不一致会报 Illegal mix of collations 错误，常见于一个表用 utf8mb4_unicode_ci，另一个用 utf8_general_ci，得显式转：CONVERT(name USING utf8mb4) COLLATE utf8mb4_unicode_ci

替代方案：PHP 合并不等于非得用 UNION

当两个查询逻辑差异大、字段结构难对齐，或其中一方要走缓存/API，硬塞进一条 UNION 反而增加维护成本和出错概率。

• 简单合并结果数组？用 array_merge()，但注意键名冲突（数字键会重排，字符串键会覆盖）
• 需要分页或统计总数？UNION 后套一层 SELECT COUNT(*) 或 SQL_CALC_FOUND_ROWS（已弃用）都不如 PHP 层分别查总数再相加来得稳
• 字段名完全不匹配？与其用 NULL AS extra_field 补位，不如在 PHP 中统一映射成标准结构：['id' => $row['user_id'] ?? $row['post_id'], 'type' => 'user']

真正卡住的往往不是语法，而是想当然认为“数据库合并”一定比“PHP 合并”快——数据量小、网络延迟低、PHP 内存够用时，后者更可控。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。