mysql中union硬性要求字段数一致且对应列类型兼容，列名以首个select为准；union去重而union all不查重更高效；php中需括号包裹子查询、独立绑定参数、统一字符集，必要时改用php合并。
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 反而增加维护成本和出错概率。
立即学习“PHP免费学习笔记（深入）”；
- 简单合并结果数组？用
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 内存够用时，后者更可控。
