mysql多条查询结果纵向拼接

标签：MySQL、UNION、UNION ALL、纵向合并、SQL优化、慢查询治理

前言

在日常开发中，我们经常需要把多条独立SELECT查询的结果上下堆叠合并，也就是纵向拼接。
很多人容易混淆两个概念：

• JOIN：横向拼接，增加列；
• UNION / UNION ALL：纵向拼接，增加行。

不少开发直接上手写UNION，遇到大数据量直接触发慢查询；同时还有LIMIT失效、排序异常、索引无法利用、跨表OR改造等一系列踩坑点。
本文系统讲解MySQL纵向拼接语法、底层差异、规范写法、高频陷阱以及线上最优实践。

一、什么是纵向拼接

横向拼接（JOIN）：两张表根据关联字段左右合并，行数重组，字段增多。
纵向拼接（UNION系列）：把多条查询结果上下堆叠，字段结构保持一致，行数累加。

示意图通俗理解：

查询A结果： id | name 1 | 张三 查询B结果： id | name 2 | 李四 纵向拼接后： id | name 1 | 张三 2 | 李四

二、基础语法与强制约束

纵向拼接依靠两个关键字：UNION、UNION ALL。

硬性规则（违反直接报错）

1. 每条子查询列数量必须完全一致；
2. 对应位置字段数据类型尽量兼容；
3. 最终字段名称由第一条SELECT决定，后续子查询别名无效；
4. 不推荐子查询使用SELECT *，字段结构变更会直接引发异常。

基础示例：

-- 纵向拼接两条查询SELECTid,usernameFROM`user`WHEREstatus=1UNIONALLSELECTid,access_keyFROM`app_key`WHEREstatus=1;

三、UNION 和 UNION ALL核心区别（重中之重）

UNION

1. 合并结果后自动全局去重；
2. MySQL底层会创建临时表、执行排序比对重复；
3. 执行计划大概率出现Using temporary; Using filesort；
4. 性能较差，大数据量慎用。

UNION = UNION ALL + DISTINCT 全局去重

UNION ALL

1. 直接原样纵向拼接，不去重、不排序；
2. 无临时表、无全局排序开销；
3. 性能远高于UNION，优先选用。

直观对比测试

存在重复数据场景：

-- UNION：自动剔除重复行SELECTuser_idFROM`user`WHEREusername='demo'UNIONSELECTuser_idFROM`app_key`WHEREaccess_key='demo_key';-- UNION ALL：保留全部记录，包含重复SELECTuser_idFROM`user`WHEREusername='demo'UNIONALLSELECTuser_idFROM`app_key`WHEREaccess_key='demo_key';

四、业务需要去重该怎么写？

不推荐：直接使用 UNION

推荐方案：UNION ALL + 外层DISTINCT

SELECTDISTINCTuser_idFROM(SELECTuser_idFROM`user`WHEREusername='demo'UNIONALLSELECTuser_idFROM`app_key`WHEREaccess_key='demo_key')t;

优势：优化器可以自主选择哈希去重，不一定强制排序，优化空间更大，线上标准写法。

五、高频踩坑：LIMIT 与 ORDER BY 作用范围

陷阱1：不加括号，LIMIT只会作用最后一条子查询

❌ 错误写法

SELECTid,usernameFROM`user`LIMIT10UNIONALLSELECTid,access_keyFROM`app_key`LIMIT10;

MySQL理解：整体合并之后只取10行，不是两条各自限制10条。

✅ 正确写法：子查询使用括号包裹

(SELECTid,usernameFROM`user`LIMIT10)UNIONALL(SELECTid,access_keyFROM`app_key`LIMIT10);

陷阱2：子查询内ORDER BY默认无效

单独写ORDER BY不会生效，只有搭配LIMIT时，括号内排序才会执行。

-- 内部排序生效(SELECTid,usernameFROM`user`ORDERBYcreate_timeDESCLIMIT5)UNIONALL(SELECTid,access_keyFROM`app_key`ORDERBYcreate_timeDESCLIMIT5);

陷阱3：想要整体结果统一排序

把全部拼接结果作为子查询，外层统一ORDER BY

SELECT*FROM((SELECTid,usernameFROM`user`LIMIT10)UNIONALL(SELECTid,access_keyFROM`app_key`LIMIT10))tORDERBYidDESC;

六、经典业务场景：跨表OR条件优化（实战高频）

原始问题SQL（性能差、逻辑存在隐患）

SELECTt1.id,t1.usernameFROM`user`t1LEFTJOIN`app_key`t2ONt1.id=t2.user_idWHEREt1.username='demo'ORt2.access_key='demo_key';

这类LEFT JOIN + OR跨表条件极易索引失效。
标准优化手段：拆分查询，UNION ALL纵向拼接

-- 场景1：匹配用户表账号SELECTid,usernameFROM`user`WHEREusername='demo'UNIONALL-- 场景2：匹配密钥表，关联查询用户SELECTt1.id,t1.usernameFROM`user`t1INNERJOIN`app_key`t2ONt1.id=t2.user_idWHEREt2.access_key='demo_key';

如需去重外层包DISTINCT，每条分支独立执行，能够正常使用各自索引。

拓展：只需要查询任意一条匹配数据（短路查询）

登录、账号检索场景，找到第一条即可返回，减少扫描：

SELECT*FROM((SELECTid,usernameFROM`user`WHEREusername='demo'LIMIT1)UNIONALL(SELECTt1.id,t1.usernameFROM`user`t1INNERJOIN`app_key`t2ONt1.id=t2.user_idWHEREt2.access_key='demo_key'LIMIT1))tmpLIMIT1;

如果第一条分支命中，数据库不需要继续执行第二条查询。

七、纵向拼接编码规范与优化建议

1. 优先使用 UNION ALL，杜绝无条件使用 UNION；只有确认必须全局去重时，使用UNION ALL + DISTINCT；
2. 不要使用SELECT *，显式指定字段，保证结构稳定；
3. 子查询需要限制行数，必须用括号包裹；
4. 多条分支查询务必建立合适索引，纵向拼接不会提升单条子查询性能；
5. 分支数量不宜过多，过多子查询可读性变差，可以考虑应用层多次查询合并；
6. 大数据场景避免上万行结果拼接，网络传输消耗较大；
7. 不要依靠UNION实现单表内部去重，单表去重直接使用DISTINCT。

八、常见误区汇总

误区1：UNION一定比UNION ALL简洁，少量数据无所谓

测试环境少量数据看不出差距；线上十万级结果集，临时表+排序会直接造成接口超时。

误区2：WHERE条件写在一起，不如UNION拼接灵活

很多跨表OR、复杂多条件检索，拆分UNION ALL是唯一能稳定走索引的方案。

误区3：子查询的字段别名全局生效

只有第一条SELECT的别名作为最终列名，后续子查询别名会被忽略。

误区4：UNION ALL内部自动去重

不会，重复记录会完整保留，必须手动处理。

九、验证手段

使用EXPLAIN分析执行计划：

• UNION：可见<union>、Using temporary、Using filesort
• UNION ALL：执行计划简洁，不存在全局临时表与排序

十、全文总结

1. MySQL纵向拼接依靠UNION / UNION ALL，作用是堆叠多行；横向合并依靠JOIN，二者不要混淆；
2. 性能铁律：优先 UNION ALL；需要去重采用 UNION ALL + DISTINCT，尽量避免直接UNION；
3. LIMIT、ORDER BY作用范围容易踩坑，子查询增加括号控制作用域；
4. LEFT JOIN + OR跨表条件慢查询，首选方案：拆分为多条查询，UNION ALL纵向拼接；
5. 任何优化的前提：每条独立子查询本身能够正常命中索引。

日常开发牢记：纵向拼接只是结果合并手段，无法提升单条查询扫描效率，优化重心依然在每条分支SQL与索引设计。