做MySQL开发这几年要说哪个功能使用频率最高联合查询绝对排在前三。业务报表、订单明细、后台列表页几乎天天跟多表关联打交道。但我也见过不少人在联合查询上栽跟头结果集不对、数据一多就卡、分页乱了、莫名其妙多出一堆重复行。这篇博文就把MySQL数据库联合查询彻底讲透JOIN和UNION两大类分别是什么原理、什么时候用、怎么写效率高、有哪些实际项目中才会遇到的坑全部用真实业务场景说话。适合刚接触数据库的初学者也适合写了好几年SQL但一直没系统梳理过的开发、运维和数据分析同学。1. 先分清你需要的到底是 JOIN 还是 UNION1.1 两种联合的本质区别很多中文教材里连接查询JOIN和合并查询UNION是严格区分的前者才叫连接后者才叫联合。但日常工作沟通中大家习惯性把所有多表操作都喊成联合查询。真要上手写SQL之前第一步是搞清楚这两类操作的结果集会怎么变JOIN横向拼接。把两张表的行按关联条件配成对结果是一行包含两张表的列列数变多。比如用户表连接订单表查出张三 他的订单号 订单金额这样更宽的行。UNION纵向堆叠。把两条SELECT的结果上下叠在一起行数变多列数不变。比如把1月份订单和2月份订单合成一个清单。打个生活化的比方JOIN像是把两张卡片用订书机钉在一起新卡片同时含有两个卡面的信息UNION像是把两副牌摞成一摞每张牌本身没有任何变化只是牌变多了。这个区别决定了你的SQL骨架。需求是订单列表里要出现用户昵称这就是要更宽的行必须JOIN需求是把所有门店的销售记录合成一个表格导出这就是要更多的行UNION更合适。方向选错了SQL写起来会处处别扭。1.2 一个判断标准结果集想要更宽还是更长我总结了一个极简判断表写SQL之前先对着想一遍数据需求特征用哪个原因需要同时展示多张表的字段订单用户昵称JOIN要的是更宽的信息行需要把多段独立结果合并成一个清单UNION要的是更多的行需要分析两个表之间匹配或未匹配的关系JOIN连接类型控制保留哪些行两段查询结构相同要合并并去重UNION纵向堆叠加去重一条记录关联多条子记录要额外算汇总JOIN GROUP BY横向拼接后按主表聚合但别机械地套。实际业务里JOIN和UNION经常组合出现比如先UNION把两个分表的数据合起来再JOIN维表补充名称。顺序无所谓关键是每一层操作你都清楚自己在干什么。我见过最混乱的SQL就是三层JOIN外加一坨UNION还夹带子查询最后根本没人能说清楚结果集到底是什么形态。写SQL跟写文章一样先定大纲再落笔。2. 连接查询JOIN的完整玩法与避坑要点2.1 内连接 INNER JOIN只保留能配成对的内连接是使用频率最高的连接类型它只返回两个表中都满足ON条件的行。SELECT u.name, o.order_no, o.amount FROM t_user u INNER JOIN t_order o ON o.user_id u.id;在这个例子里只有用户表有对应记录、订单表也有有效user_id的行才会出现在结果里。没有下过单的用户不会出现订单挂了无效用户的也不会出现。这就是内的含义——只取交集。实际开发中很多人直接写JOIN而不写INNER因为MySQL默认就是内连接。我的建议是简单查询可以从简但三张表以上的关联一定要明确写出JOIN类型否则过两周你自己回来看这段SQL都得靠猜才知道当初想干嘛。另外内连接的ON条件等价于WHERE里的关联条件你把过滤条件写进WHERE也一样能跑但为了可读性和迁移性关联逻辑放ON、单表过滤逻辑放WHERE这个习惯要从一开始养好。2.2 左连接 LEFT JOIN左表永远是主角左连接会把左表的每一行都保留下来右表有匹配就带上右表数据没匹配就补NULL。这是业务系统里最常用的连接类型因为主表全保留、从表可缺失的场景太普遍了。SELECT u.name, COUNT(o.id) AS order_cnt FROM t_user u LEFT JOIN t_order o ON o.user_id u.id GROUP BY u.id, u.name;这个查询统计每个用户的订单数没下过单的用户也会出现订单数显示为0。注意这里必须用COUNT(o.id)而不是COUNT()因为COUNT()会把右表NULL的行也算进去。这是个极其经典的坑后文我还会详细说。至于RIGHT JOIN它的语义就是左连接的镜像把右表当主角。实际工作中我基本不写RIGHT JOIN因为把整段SQL左右反过来写成LEFT JOIN阅读习惯上更顺畅。如果你发现自己在一堆LEFT JOIN中间夹了一个RIGHT JOIN考虑是不是连接顺序本身可以调整一下。2.3 自连接与交叉连接容易被忽略的两种变体自连接是同一张表跟自己关联。典型场景是层级关系比如员工表里存了manager_id指向本表的idSELECT e.name AS employee, m.name AS manager FROM t_employee e LEFT JOIN t_employee m ON e.manager_id m.id;自连接的关键是必须给表起不同的别名否则字段都无法区分。用LEFT JOIN而不是INNER JOIN是为了让没有上级的顶层员工也出现在结果里。交叉连接CROSS JOIN则是另一个极端——它产生笛卡尔积即两表的每一行都互相组合。多数情况下这是灾难但个别场景确实需要比如用日期表交叉门店表生成排班模板SELECT d.day, s.store_name FROM t_date d CROSS JOIN t_store s;写CROSS JOIN前必须清醒地意识到你想不想要全组合两万行的表交叉两万行的表结果就是四亿行这能把任何一个数据库瞬间压垮。我见过有人漏写ON条件导致隐式笛卡尔积结果接口超时的线上事故后面会展开讲。2.4 ON 和 WHERE 的区别最容易出错的写法这是LEFT JOIN里最经典的一个坑。同样的过滤条件写在ON里和写在WHERE里结果可能完全不同。-- 错误示范想查所有用户及其未取消的订单 SELECT u.name, o.order_no FROM t_user u LEFT JOIN t_order o ON o.user_id u.id WHERE o.status valid;这个查询跑出来没下过单的用户全部消失了跟INNER JOIN结果一样。原因在于LEFT JOIN拼接时右表匹配不上会补NULLWHERE是在拼接完成之后才执行的NULL行无法通过o.status valid的判断于是被过滤掉。正确的写法是把右表的过滤条件放进ONSELECT u.name, o.order_no FROM t_user u LEFT JOIN t_order o ON o.user_id u.id AND o.status valid;这样语义就变成了左表全部保留右表只拿status为valid的订单参与拼接。对LEFT JOIN来说ON决定右表哪些行参与匹配WHERE决定整个结果集里保留哪些行。左表自身的过滤条件放WHERE没问题但为了不让自己下次看代码时犯迷糊我建议关联条件一律放ON单表条件也大多放ONWHERE里只留针对最终结果集的过滤。3. 合并查询UNION / UNION ALL的实操细节3.1 UNION 与 UNION ALL选错了会慢一个量级UNION和UNION ALL的区别只有一个UNION会去重UNION ALL不去重。但这个只差一步的操作性能差距可能是一个数量级。UNION在合并之后要做去重MySQL内部通常需要排序或者哈希去重数据量一上去开销非常明显。UNION ALL就是纯堆叠把两个结果集直接接在一起几乎零额外成本。SELECT order_no, amount FROM t_order_jan UNION SELECT order_no, amount FROM t_order_feb;如果业务上两段数据本来就不同源、不会重复却用了UNION那数据库就是在做无用功。我给一个经验法则场景用哪个原因两个分表的订单号段互不重叠UNION ALL去重逻辑本身就不需要需要生成一个去重后的清单UNION自动去重省得自己处理数据量大、对实时性有要求UNION ALL避免排序和哈希开销不确定是否重复但业务允许重复UNION ALL重复后应用层或后续处理结果必须严格无重复UNION语义正确优先多数统计场景我默认用UNION ALL只有在业务上明确不能出现重复行时才用UNION。3.2 列数、列名与类型合并查询的三条铁律UNION有非常硬性的约束各分支SELECT出来的列数必须一致列的对齐按位置不按列名最终结果集的列名以第一个SELECT为准。SELECT id, name FROM t_user UNION ALL SELECT user_id, nick_name FROM t_user_archive;这段SQL的结果集列名叫id和name第二段的列名被完全忽略。如果列数不一致直接报错The used SELECT statements have a different number of columns。这是初学者最常见的报错原因。类型问题更隐蔽。如果两段对应列类型不一致MySQL会做隐式转换轻则结果类型变窄重则数据失真。比如一个是VARCHAR的00123另一个是INT的123UNION后可能变成123。我的建议是写UNION前先对齐类型必要时用CAST统一转换别让数据库替你猜。另外需要排序或分组时引用结果集列名要格外小心因为最终列名只来自第一个分支。3.3 两个高频场景冷热数据合并与多维度统计第一个场景是从冷热表合并里取数据。很多系统会把历史订单归档到独立表结构跟当前订单表一模一样。查询的时候就靠UNION ALL把两地数据接起来SELECT order_no, user_id, amount, create_time FROM t_order WHERE create_time 2025-01-01 UNION ALL SELECT order_no, user_id, amount, create_time FROM t_order_archive WHERE create_time 2025-01-01;注意这种写法在分页时有个陷阱如果先各取LIMIT再UNION结果就漏了必须全部合并后再统一ORDER BY和LIMIT这个后文展开讲。第二个场景是多维度统计的并排展示。用字面量给每段结果打标签特别适合做日报、周报SELECT 今日 AS period, COUNT(*) AS cnt FROM t_daily_log WHERE log_date CURDATE() UNION ALL SELECT 昨日, COUNT(*) FROM t_daily_log WHERE log_date DATE_SUB(CURDATE(), INTERVAL 1 DAY);3.4 顺带说一句为什么安全圈子总提到 UNION搜索联合查询的高频关联词里有个ctfshow的联合查询注入。很多CTF题目拿UNION做文章本质上是因为UNION要求两个查询的列数一致攻击者可以利用报错信息或ORDER BY试探出目标查询的列数再把自己构造的查询结果拼到回显位置从而把库名、表名、字段值直接打到页面上。对开发人员来说了解这个不是去研究攻击手法而是要真正理解防御的必要性所有外部输入必须走参数化查询绝不允许字符串拼接SQL数据库账号遵循最小权限原则应用账号不该有访问所有库的权限生产环境关闭详细的报错输出。原理搞明白了写代码时就会条件反射地避开危险的拼接写法。理解背后的机制恰恰是写出安全代码的前提。3.5 排序和分页UNION 里最容易踩的坑MySQL里UNION各分支中的ORDER BY如果没带LIMIT会被优化器直接无视。这是最迷惑人的一个坑。-- 这样写两个分支内的排序都会被忽略 SELECT order_no, amount FROM t_order_jan ORDER BY amount DESC UNION ALL SELECT order_no, amount FROM t_order_feb ORDER BY amount DESC;想要全局排序必须把ORDER BY写在最后一个分支的后面SELECT order_no, amount FROM t_order_jan UNION ALL SELECT order_no, amount FROM t_order_feb ORDER BY amount DESC;如果确实需要先对每个分支各自取TOP-N再合并那就得配合LIMIT并用括号包住分支查询(SELECT order_no, amount FROM t_order_jan ORDER BY amount DESC LIMIT 10) UNION ALL (SELECT order_no, amount FROM t_order_feb ORDER BY amount DESC LIMIT 10);这个括号写法很多人不知道其实MySQL是支持的。先分支取Top再合并再整体排序是处理分表TopN汇总这种需求的标准姿势。4. 性能优化怎么让联合查询跑得又快又稳4.1 关联字段索引一半以上的性能收益在这JOIN的性能命脉是关联字段的索引。MySQL最常用的连接算法是Nested Loop Join也就是嵌套循环外层每取一行内层就要去查找一遍匹配行。如果内层表关联字段没有索引每次匹配都是全表扫描复杂度直接变成O(N×M)数据量稍大就卡死。ALTER TABLE t_order ADD INDEX idx_user_id (user_id);这是一个真实案例两张各二十万行的表做JOIN没索引时查询跑了将近三十秒建上索引之后瞬间变成0.1秒以内。三百倍的差距全来自一个索引。我排查过的慢查询里至少一半以上都是这个原因。注意一点MySQL 8.0.18之后的版本无索引的等值连接也可能走Hash Join性能会比老版本的嵌套循环好很多但依然远不如索引带来的收益。别指望Hash Join兜底索引该建还是得建。另外外键约束和JOIN索引并不是一回事不要以为表结构里定义了FOREIGN KEY就万事大吉业务表经常因为各种原因没建物理外键索引需要单独确认。4.2 小表驱动大表理解连接顺序的底层逻辑既然JOIN本质是嵌套循环那外层循环次数越少越好就是铁律。所谓小表驱动大表就是让数据量小的表做外层驱动表让数据量大的表做内层被驱动表配合索引做匹配。这样内层查找的次数 驱动表的行数。五万行的表驱动两百万行的表内层只需要做五万次索引查找反过来让两百万的表做驱动就是两百万次查找。这个差距是决定性的。好消息是MySQL优化器会基于统计信息和成本模型自动选连接顺序绝大多数情况下不用手动干预。但有两种情况要当心一是统计信息不准确二是表结构复杂导致成本估算偏差。这时可以看看EXPLAIN的输出确认驱动表是否符合预期。必要时可以用STRAIGHT_JOIN强制指定连接顺序但这是最后的手段别一上来就用因为数据分布变化后强制顺序可能反而更慢。4.3 别用 SELECT *字段取舍影响覆盖索引JOIN和UNION查询里随手写SELECT *的代价比单表查询更大。多取了用不到的列网络传输和内存占用成倍增加更关键的是可能破坏覆盖索引。覆盖索引的意思是查询需要的所有列都能从索引里拿到不需要回表。比如表上有联合索引(user_id, name)而查询只选了这两列数据库扫完索引直接返回省掉一次主键回表。但如果你SELECT *那必然要回表查其余字段覆盖索引就失效了。-- 只查需要的列有机会命中覆盖索引 SELECT u.id, u.name, o.user_id FROM t_user u LEFT JOIN t_order o ON o.user_id u.id;顺便说一句如果表里还有TEXT、BLOB这类大字段SELECT *会把它们整段拖出来对网络和内存的冲击非常大。这个习惯必须戒掉。4.4 EXPLAIN排查慢查询的唯一正确入口遇到慢查询第一件事永远是EXPLAIN而不是凭感觉加索引或者改SQL结构。EXPLAIN SELECT u.name, o.order_no FROM t_user u LEFT JOIN t_order o ON o.user_id u.id WHERE u.status 1;EXPLAIN输出的关键字段就那几个字段关注点typeALL代表全表扫描ref是普通索引查找eq_ref是主键或唯一索引查找const是常量key实际使用的索引NULL表示没走索引rows预估扫描行数这个数字异常大就要警惕Extra出现Using filesort或Using temporary要格外小心我自己的排查习惯是先看type有没有ALL再看rows合不合理最后扫一眼Extra有没有临时表和文件排序。绝大多数慢查询问题EXPLAIN一眼就能给出答案。联合查询尤其要看连接顺序第一行一般是驱动表被驱动表的type如果出现ALL十有八九是索引没建上。5. 常见问题速查表与排查实录5.1 笛卡尔积爆炸一次印象深刻的翻车先给一张速查表都是高频问题现象可能原因解决办法结果行数暴增几万倍忘写ON条件或ON条件写错检查JOIN后是否有ON关联字段是否正确LEFT JOIN后左表行消失右表过滤条件写到了WHERE把过滤条件移到ON里UNION结果莫名很慢用了UNION自动去重允许重复就改用UNION ALL分支配序失效分支单独ORDER BY但没带LIMIT整体排序放最后或括号加LIMIT报错ambiguous字段名歧义多表同名字段没加别名所有字段统一用别名.字段名JOIN后再分页数据乱先LIMIT后JOIN或JOIN后LIMIT语义不清确认分页粒度必要时先子查询分页再JOIN笛卡尔积是最吓人的一个。我之前做过一个商品标签统计当时用了逗号连接的老式写法FROM t_tag_a, t_tag_b忘了加WHERE关联条件。八千米的标签表和六千的标签表一交叉四千八百万行直接拍在数据库脸上接口超时、数据库CPU飙满。要记住逗号分隔的隐式连接等价于CROSS JOIN忘写条件就一定会产生笛卡尔积。与其等着踩雷不如老老实实写显式JOINON条件放在一眼能看到的地方。5.2 JOIN 与分页的顺序先缩小还是先关联多表JOIN后再分页顺序选不对性能差距极大。-- 低效写法先JOIN出大量中间结果再分页 SELECT u.name, o.order_no FROM t_user u LEFT JOIN t_order o ON o.user_id u.id ORDER BY u.id LIMIT 20 OFFSET 0;这条SQL在数据量大的时候会先把所有匹配行全部算出来排序后再丢弃大部分浪费严重。更优的思路是先对主表分页再JOINSELECT u.name, o.order_no FROM (SELECT id, name FROM t_user ORDER BY id LIMIT 20 OFFSET 0) u LEFT JOIN t_order o ON o.user_id u.id;这里有个语义细节必须讲清楚如果用户和订单是一对多第二种写法分页的粒度是按用户来的每页20个用户每个用户带出自己的订单。如果业务要求的是最终结果行每页20条那分页粒度不同不能用第二种。这就是我反复强调先想清楚结果形态再写SQL的原因——同一个需求换一个表述SQL结构就完全变了。5.3 NULL 值陷阱LEFT JOIN 结果比预期少LEFT JOIN无匹配时右表字段是NULL这本身是设计好的行为但NULL会在各种意想不到的地方给你添乱。COUNT()和COUNT(字段)的差异就是一个典型。统计订单数时COUNT()会把右表全NULL的行也数进去导致结果偏大COUNT(o.id)则跳过NULL。两个结果不一致只有一种解释存在没匹配上的LEFT JOIN行这本身可能就意味着数据问题值得排查。更隐蔽的是ON条件里的不等于判断。比如你想排除已取消的订单写成o.status cancelSQL语义上NULL永远不会通过这个判断于是右表无匹配的行就进不了结果。这种情况要显式处理LEFT JOIN t_order o ON o.user_id u.id AND COALESCE(o.status, ) cancel;连接条件本身也怕NULL。NULL和任何值都不相等包括NULL自己所以ON xxx.user_id yyy.user_id在两个user_id都为NULL时是匹配不上的。如果业务里关联字段允许为NULL要用运算符或者IS NULL专门处理否则那些NULL行会在JOIN里静默丢失。5.4 字段歧义给表起别名是最低成本的规范多表JOIN时不同表里经常有相同的字段名最常见的就是id、name、status。不加前缀直接SELECT idMySQL直接报Column id in field list is ambiguous。这个问题的根治方法不是出错后改SQL而是从一开始就养成规范每个表起一个短而明确的别名t_user起成ut_order起成o查询里的所有字段都带上别名前缀u.name、o.order_no连接字段的命名尽量统一比如订单表里存user_id用户表主键叫id关联时一眼就能看出来是o.user_id u.id。这套习惯成本极低但维护价值很高。我接手过的老项目里三四个表JOIN后字段裸奔、全靠猜的SQL不在少数改一次需求光梳理字段就耗掉半天。命名规范不是为了好看是为了让三个月后的你自己少受罪。6. 最后分享两个实践习惯说实话联合查询这四五年我写了几千遍真正觉得懂了是在一次线上事故之后。当时一个运营后台的报表查询三张表JOIN之后跑了几分钟数据库CPU被打满。我一条条看EXPLAIN最后发现其中一张表的关联字段没有索引。加上索引之后查询直接从几分钟变成几百毫秒。从那以后我养成了两个雷打不动的习惯第一任何JOIN、UNION查询上线前必看EXPLAIN确认没有全表扫描、没有超大rows估算第二先写清楚业务到底要什么数据形态再决定用JOIN还是UNION绝不凭感觉堆SQL。还有一个技巧是拿自己的业务表把所有例子手动跑一遍跑的时候观察EXPLAIN的变化同一个需求换一种写法rows估算差多少、Extra里有没有Using filesort这些都看一遍比读一百篇教程都实在。联合查询不难难的是养成先想清楚、再动手、再验证的习惯。