标签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。硬性规则违反直接报错每条子查询列数量必须完全一致对应位置字段数据类型尽量兼容最终字段名称由第一条SELECT决定后续子查询别名无效不推荐子查询使用SELECT *字段结构变更会直接引发异常。基础示例-- 纵向拼接两条查询SELECTid,usernameFROMuserWHEREstatus1UNIONALLSELECTid,access_keyFROMapp_keyWHEREstatus1;三、UNION 和 UNION ALL核心区别重中之重UNION合并结果后自动全局去重MySQL底层会创建临时表、执行排序比对重复执行计划大概率出现Using temporary; Using filesort性能较差大数据量慎用。UNION UNION ALL DISTINCT 全局去重UNION ALL直接原样纵向拼接不去重、不排序无临时表、无全局排序开销性能远高于UNION优先选用。直观对比测试存在重复数据场景-- UNION自动剔除重复行SELECTuser_idFROMuserWHEREusernamedemoUNIONSELECTuser_idFROMapp_keyWHEREaccess_keydemo_key;-- UNION ALL保留全部记录包含重复SELECTuser_idFROMuserWHEREusernamedemoUNIONALLSELECTuser_idFROMapp_keyWHEREaccess_keydemo_key;四、业务需要去重该怎么写不推荐直接使用 UNION推荐方案UNION ALL 外层DISTINCTSELECTDISTINCTuser_idFROM(SELECTuser_idFROMuserWHEREusernamedemoUNIONALLSELECTuser_idFROMapp_keyWHEREaccess_keydemo_key)t;优势优化器可以自主选择哈希去重不一定强制排序优化空间更大线上标准写法。五、高频踩坑LIMIT 与 ORDER BY 作用范围陷阱1不加括号LIMIT只会作用最后一条子查询❌ 错误写法SELECTid,usernameFROMuserLIMIT10UNIONALLSELECTid,access_keyFROMapp_keyLIMIT10;MySQL理解整体合并之后只取10行不是两条各自限制10条。✅ 正确写法子查询使用括号包裹(SELECTid,usernameFROMuserLIMIT10)UNIONALL(SELECTid,access_keyFROMapp_keyLIMIT10);陷阱2子查询内ORDER BY默认无效单独写ORDER BY不会生效只有搭配LIMIT时括号内排序才会执行。-- 内部排序生效(SELECTid,usernameFROMuserORDERBYcreate_timeDESCLIMIT5)UNIONALL(SELECTid,access_keyFROMapp_keyORDERBYcreate_timeDESCLIMIT5);陷阱3想要整体结果统一排序把全部拼接结果作为子查询外层统一ORDER BYSELECT*FROM((SELECTid,usernameFROMuserLIMIT10)UNIONALL(SELECTid,access_keyFROMapp_keyLIMIT10))tORDERBYidDESC;六、经典业务场景跨表OR条件优化实战高频原始问题SQL性能差、逻辑存在隐患SELECTt1.id,t1.usernameFROMusert1LEFTJOINapp_keyt2ONt1.idt2.user_idWHEREt1.usernamedemoORt2.access_keydemo_key;这类LEFT JOIN OR跨表条件极易索引失效。标准优化手段拆分查询UNION ALL纵向拼接-- 场景1匹配用户表账号SELECTid,usernameFROMuserWHEREusernamedemoUNIONALL-- 场景2匹配密钥表关联查询用户SELECTt1.id,t1.usernameFROMusert1INNERJOINapp_keyt2ONt1.idt2.user_idWHEREt2.access_keydemo_key;如需去重外层包DISTINCT每条分支独立执行能够正常使用各自索引。拓展只需要查询任意一条匹配数据短路查询登录、账号检索场景找到第一条即可返回减少扫描SELECT*FROM((SELECTid,usernameFROMuserWHEREusernamedemoLIMIT1)UNIONALL(SELECTt1.id,t1.usernameFROMusert1INNERJOINapp_keyt2ONt1.idt2.user_idWHEREt2.access_keydemo_keyLIMIT1))tmpLIMIT1;如果第一条分支命中数据库不需要继续执行第二条查询。七、纵向拼接编码规范与优化建议优先使用 UNION ALL杜绝无条件使用 UNION只有确认必须全局去重时使用UNION ALL DISTINCT不要使用SELECT *显式指定字段保证结构稳定子查询需要限制行数必须用括号包裹多条分支查询务必建立合适索引纵向拼接不会提升单条子查询性能分支数量不宜过多过多子查询可读性变差可以考虑应用层多次查询合并大数据场景避免上万行结果拼接网络传输消耗较大不要依靠UNION实现单表内部去重单表去重直接使用DISTINCT。八、常见误区汇总误区1UNION一定比UNION ALL简洁少量数据无所谓测试环境少量数据看不出差距线上十万级结果集临时表排序会直接造成接口超时。误区2WHERE条件写在一起不如UNION拼接灵活很多跨表OR、复杂多条件检索拆分UNION ALL是唯一能稳定走索引的方案。误区3子查询的字段别名全局生效只有第一条SELECT的别名作为最终列名后续子查询别名会被忽略。误区4UNION ALL内部自动去重不会重复记录会完整保留必须手动处理。九、验证手段使用EXPLAIN分析执行计划UNION可见union、Using temporary、Using filesortUNION ALL执行计划简洁不存在全局临时表与排序十、全文总结MySQL纵向拼接依靠UNION / UNION ALL作用是堆叠多行横向合并依靠JOIN二者不要混淆性能铁律优先 UNION ALL需要去重采用 UNION ALL DISTINCT尽量避免直接UNIONLIMIT、ORDER BY作用范围容易踩坑子查询增加括号控制作用域LEFT JOIN OR跨表条件慢查询首选方案拆分为多条查询UNION ALL纵向拼接任何优化的前提每条独立子查询本身能够正常命中索引。日常开发牢记纵向拼接只是结果合并手段无法提升单条查询扫描效率优化重心依然在每条分支SQL与索引设计。