MySQL 连接查询实战：内连、外连与性能优化-代码聚汇网

MySQL 连接查询实战：内连、外连与性能优化

徐小疼·2026-09-01·阅读 22 GEO检测（免费）

MySQLJOIN内连接

|难度：普通|阅读约 31 分钟

1. 从一个多表查询场景说起：为什么内连外连是日常刚需

前阵子做电商后台的报表需求，运营提了个看似简单的单子：要一份订单明细，里面带上下单用户的真实姓名。订单在 order 表，用户信息在 user 表，两张表通过 user_id 关联。我刚入行的时候会写子查询，SELECT user_id, (SELECT name FROM user WHERE id = order.user_id) FROM order，数据量小没感觉，等单表几百万行之后，子查询的性能问题就非常明显了。

后来学会了 JOIN，才意识到 MySQL 表连接语法其实才是这类需求的正解。内连、外连这两个词看着抽象，说白了一件事：两张表怎么按条件拼成一张宽表，保留哪些行、丢掉哪些行。这也是为什么 MySQL 面试题里连接查询永远是高频，因为它不是背出来的语法，而是几乎每天都在用的数据加工逻辑。

这篇文章我不会只讲 SQL 怎么写，而是把内连（INNER JOIN）、左外连（LEFT JOIN）、右外连（RIGHT JOIN）、全外连（FULL JOIN）这几种连接方式放在实际业务场景里拆开讲。每一段都会给出可以直接跑的 SQL 示例和踩坑点，适合刚接触 SQL 的新手，也适合写了一段时间但容易混淆 ON 和 WHERE、COUNT 和 NULL 关系的同学。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 内连的逻辑：笛卡尔积、关联条件和只留交集

2.1 内连到底在做什么

先说一个很容易被忽略的基础概念：两张表 JOIN 的时候，数据库引擎第一步会做笛卡尔积，也就是把 A 表的每一行和 B 表的每一行两两组合。如果 A 表 100 行、B 表 200 行，笛卡尔积就是 100 × 200 = 20000 行。INNER JOIN 后面的 ON 条件，可以理解为在这个 20000 行的中间结果里做筛选，最后只保留满足关联条件的行。

这个逻辑听起来简单，但很多人写 SQL 时容易犯一个错：写了 JOIN 却忘记带 ON 条件。比如：

sql复制SELECT u.name, o.amount
FROM user u
INNER JOIN order o;

如果不小心漏了 ON，MySQL 不会报错，而是直接返回笛卡尔积，结果行数飙升到两表行数乘积。订单 10 万行、用户 5 万行，查出来就是 50 亿行，前端直接卡死。我见过不止一次因为这种低级失误把测试库搞慢的情况。所以第一条忠告：写完 JOIN 立刻检查 ON 有没有跟上，尤其是复制粘贴出来的 SQL。

2.2 正确的内连姿势和关联字段选择

内连的标准写法是这样：

sql复制SELECT
    u.id AS user_id,
    u.name AS user_name,
    o.order_id,
    o.amount
FROM user u
INNER JOIN order o ON o.user_id = u.id;

这里 INNER 关键字可以省略，直接写 JOIN 也代表内连。关联条件是 o.user_id = u.id，意思是订单表里的 user_id 能在用户表里找到同样 id 的行，两个表就会拼成一行。

关联字段建议遵循一个原则：用主键关联外键，而不是用姓名、部门这种业务字段关联。主键具备唯一性，Join 的结果是可控的。如果用一个非唯一字段关联，比如根据城市名去关联，结果可能会出现一对多、多对多，行数直接放大，事后排查非常痛苦。

2.3 内连只保留“双方都对得上”的行

内连的关键特性是：A 表存在但 B 表没有匹配，或者 B 表存在但 A 表没有匹配，这些行统统会被丢。举个例子：order 表里有 10 笔订单，其中 1 笔订单的 user_id 指向一个已被删除的用户。内连结果只有 9 行，那笔没有用户的订单不会显示。

很多业务需求恰恰是要保留这些“没有匹配”的行。比如运营要统计注册用户里到底有多少人没下过单，如果用内连，没下过单的用户直接就没了，结果永远是 0，逻辑上就错了。这就是外连登场的地方。

连接类型	保留规则	无匹配时表现
INNER JOIN	仅保留双方都匹配的行	行直接消失
LEFT JOIN	保留左表全部行	右表字段填 NULL
RIGHT JOIN	保留右表全部行	左表字段填 NULL

3. 左外连的留空规则：主表决定 NULL 从哪来

3.1 左连接以左表为基准

LEFT JOIN，全称 LEFT OUTER JOIN，作用是以左边的表为主表，遍历左表每一行，去右表找匹配记录；能找到就拼接右表对应字段，找不到右表字段就填 NULL。这个概念是外连里最常考核的点，也是写统计报表时的核心思路。

还是用用户和订单举例。要统计每个用户的下单数量，包括从未下过单的用户，写成左连接：

sql复制SELECT
    u.id,
    u.name,
    COUNT(o.order_id) AS order_count
FROM user u
LEFT JOIN order o ON o.user_id = u.id
GROUP BY u.id, u.name;

这条 SQL 从左表 user 出发，所有用户都会出现在结果里。没下过单的用户，o.order_id 是 NULL，COUNT(o.order_id) 统计出来就是 0，完全符合业务预期。

3.2 COUNT 和 NULL 的相爱相杀

这里有一个非常隐蔽的坑：COUNT(*) 和 COUNT(字段) 对 NULL 的处理不一样。

COUNT(*) 统计的是结果集的行数，不管字段是否为 NULL。
COUNT(具体字段) 只统计该字段非 NULL 的行数。

如果把上面的 SQL 改成 COUNT()，结果就完全变了。没下过单的用户也会被算成 1 单，因为 LEFT JOIN 之后左表那一行仍然存在，COUNT() 会把它数进去。这个 bug 很容易在代码评审里漏掉，因为不是每次都复现，只有当你去核对无订单用户数量时才会发现数字对不上。

我的习惯是：统计“有没有”用 COUNT(右表主键字段) 或者 COUNT(DISTINCT 右表主键字段)；统计“总行数”才用 COUNT(*)。尤其在 LEFT JOIN 场景下，COUNT 的字段归属一定要想清楚。

3.3 用 IS NULL 筛选未匹配的行

左连接还有一个高频用途：找出“在一张表里存在、在另一张表里不存在”的孤儿数据。比如找出所有没有下单的用户：

sql复制SELECT
    u.id,
    u.name
FROM user u
LEFT JOIN order o ON o.user_id = u.id
WHERE o.order_id IS NULL;

这里 WHERE o.order_id IS NULL 的意思是：订单表里没有匹配到任何行。很多初学者会写成 WHERE o.order_id IS NOT NULL 来找“有订单的用户”，这在逻辑上也能用，但要注意 NULL 的参与方式。NULL 和数字比较时结果永远是未知，所以只能用 IS NULL 或 IS NOT NULL 判断，不能写成 o.order_id = NULL。

另外，用 EXISTS 也能实现同样的效果，而且在大数据量下往往性能更好：

sql复制SELECT
    u.id,
    u.name
FROM user u
WHERE NOT EXISTS (
    SELECT 1 FROM order o WHERE o.user_id = u.id
);

至于哪条更快，取决于数据分布和索引，不能一概而论。但语义上两种写法都能表达“左表有、右表没有”的需求，面试时能说出这两种方案的取舍，会显得你理解得更深。

4. 右外连的镜像逻辑与全外连的 UNION 拼装

4.1 RIGHT JOIN 本质上和 LEFT JOIN 是一回事

RIGHT JOIN 以右表为主表，遍历右表每一行，去左表找匹配记录，找不到左表字段就填 NULL。从逻辑上看，它和 LEFT JOIN 就是镜像关系，完全可以通过交换表的顺序把 RIGHT JOIN 改写成 LEFT JOIN。

比如：

sql复制SELECT
    u.name,
    o.order_id
FROM order o
RIGHT JOIN user u ON u.id = o.user_id;

等价于：

sql复制SELECT
    u.name,
    o.order_id
FROM user u
LEFT JOIN order o ON o.user_id = u.id;

两者只是把主表放在左边还是右边的问题。实际开发中，为了让 SQL 的阅读顺序符合“先主后从”的直觉，我几乎只用 LEFT JOIN，很少用 RIGHT JOIN。但面试官可能会问右边连接，你要知道它是什么、怎么改写，避免在代码评审时被别人问住。

4.2 全外连：MySQL 8.0 至今没有原生支持

FULL OUTER JOIN 会保留两张表的全部行，不管是否匹配。没有匹配的行，另一侧字段填 NULL。这在很多数据库里都有原生支持：PostgreSQL 有 FULL OUTER JOIN，SQL Server 有，Oracle 也有。但 MySQL 比较特殊，一直到 8.0 版本还没有提供 FULL OUTER JOIN 关键字，只能通过 LEFT JOIN 和 RIGHT JOIN 合并来实现。

常见写法是把左连接和右连接的结果用 UNION 合并，UNION 自带去重效果：

sql复制SELECT
    u.id AS user_id,
    u.name,
    o.order_id
FROM user u
LEFT JOIN order o ON o.user_id = u.id

UNION

SELECT
    u.id AS user_id,
    u.name,
    o.order_id
FROM user u
RIGHT JOIN order o ON o.user_id = u.id;

第一段能取出所有用户以及他们匹配到的订单；第二段能取出所有订单以及它们对应的用户。UNION 会把两边重复的行合并掉，最终得到所有用户和所有订单的全量关联结果。

4.3 全外连的应用场景：对账

全外连最常见的场景是对账。假设有两套系统分别维护“支付流水表”和“发货流水表”，需要找出哪些支付没有发货、哪些发货没有支付，同时把正常匹配的流水展示出来。用 FULL JOIN 的思想做全量匹配，然后根据两侧是否为空进行标记，一屏就能看清所有异常。

用 UNION 模拟时，还可以在 SELECT 里加一个来源标记字段，方便区分行来自哪一边：

sql复制SELECT
    COALESCE(u.id, o.user_id) AS user_id,
    u.name,
    o.order_id,
    CASE
        WHEN u.id IS NULL THEN 'order_only'
        WHEN o.order_id IS NULL THEN 'user_only'
        ELSE 'matched'
    END AS match_status
FROM user u
LEFT JOIN order o ON o.user_id = u.id

UNION

SELECT
    COALESCE(u.id, o.user_id),
    u.name,
    o.order_id,
    CASE
        WHEN u.id IS NULL THEN 'order_only'
        WHEN o.order_id IS NULL THEN 'user_only'
        ELSE 'matched'
    END
FROM user u
RIGHT JOIN order o ON o.user_id = u.id;

COALESCE 的作用是从多个参数里取第一个非 NULL 值。在 FULL JOIN 的场景里，主键字段可能来自左表也可能来自右表，用 COALESCE 可以把它们归并成一个统一字段。这个技巧在数据清洗时非常实用。

5. ON 和 WHERE 的位置没有弄明白，结果错得离谱

5.1 内连里 ON 和 WHERE 看似等价，逻辑上不一样

在内连场景下，把过滤条件写在 ON 后面还是 WHERE 后面，结果通常是相同的，因为内连只保留匹配行，先过滤再匹配和先匹配再过滤不会改变最终输出。但语义上，ON 描述的是两表之间的关联关系，WHERE 描述的是对关联结果行的筛选条件。

很多人对内连的”等价“印象根深蒂固，到了外连也直接套用，结果就出事了。

5.2 左外连里条件放错位置，左表会被悄悄掏空

这是最经典的一道 SQL 面试题，也是实际开发中踩得最多的一坑。需求还是用户和订单，这次要查所有用户，但只要他们已支付的订单金额，没有订单或者订单未支付的用户也要出现在结果里。

很多人会这么写：

sql复制SELECT
    u.name,
    o.amount
FROM user u
LEFT JOIN order o ON o.user_id = u.id
WHERE o.status = 'paid';

这条 SQL 的结果是：只有存在已支付订单的用户才会出现。为什么？因为 WHERE 是在 LEFT JOIN 完成之后才执行的过滤条件。未支付订单的那一行，o.status 是其他值，被过滤掉；没有订单的用户，o.status 是 NULL，WHERE 判断 NULL = 'paid' 结果不是 TRUE，也被过滤掉。最终 LEFT JOIN 保留左表全部行的特性被 WHERE 破坏，效果等同于内连。

如果把条件挪到 ON 里：

sql复制SELECT
    u.name,
    o.amount
FROM user u
LEFT JOIN order o ON o.user_id = u.id AND o.status = 'paid';

结果就不一样了。这个写法先按“用户ID相等且订单状态为已支付”这两个条件去匹配右表；没匹配上的用户，右表整行仍为 NULL，但左表用户行依然保留。这正是“所有用户都在，但只显示已支付订单”的意思。

ON 里的关联条件再多也不影响主表保留行的数量，WHERE 里的条件是对最终结果集的二次筛选。这条规则是判断 SQL 结果是否符合预期的重要依据。

5.3 条件放置的决策建议

我个人总结的经验是：凡是关于“右表数据的限定”，如果不想影响左表的主行存在性，就放在 ON 里；凡是关于“最终展示结果”的过滤，比如时间范围、状态筛选，放在 WHERE 里更直观。但要注意，一旦放在 WHERE 里，过滤掉的是拼好的整行，左表也会跟着消失。这个特性在面试中通常会被反复追问，答不上来说明对外连的理解还停留在语法层面。

6. 多表串联：订单、用户、商品三表连接的实际推演

6.1 从两表连接扩展到三表连接

现实业务很少只有两张表。一个标准订单查询通常涉及用户表、订单表、订单明细表、商品表四张表。拿一个简化版本示例：用户下单，每个订单有若干明细，每个明细对应一个商品。现在要查每个用户买了哪些商品、数量、单价，SQL 可以连续 JOIN：

sql复制SELECT
    u.name,
    p.product_name,
    oi.quantity,
    oi.price
FROM user u
LEFT JOIN order o ON o.user_id = u.id
LEFT JOIN order_item oi ON oi.order_id = o.order_id
LEFT JOIN product p ON p.product_id = oi.product_id
ORDER BY u.id, o.order_id;

这里每张表的 JOIN 顺序是按业务关系从左往右延伸的：用户 -> 订单 -> 明细 -> 商品。每 JOIN 一张表就相当于往宽表里追加新列，如果哪一侧没有匹配到，新追加的字段就置 NULL。多表连接时，主表的选择依然决定最终的行保留范围。这个例子里以 user 为主表，表示所有用户都会出现。

6.2 JOIN 导致行数膨胀后的聚合陷阱

多表连接最头疼的问题是一对多导致行数膨胀。假设一个订单有 3 条明细，订单表和明细表 JOIN 后，这个订单会变成 3 行。这时候再对订单的金额字段做 SUM，金额就会被重复计算 3 次，统计结果直接翻倍。

sql复制-- 错误示例：会重复计算订单金额
SELECT
    o.order_id,
    SUM(o.amount) AS total_amount,
    COUNT(oi.id) AS item_count
FROM order o
LEFT JOIN order_item oi ON oi.order_id = o.order_id
GROUP BY o.order_id;

这里 o.amount 属于订单表，订单有 3 条明细，JOIN 后同一订单出现 3 次，SUM(o.amount) 相当于把金额加了 3 次。解决办法有三种思路：

第一种，先对明细表做聚合，再和订单表连接：

sql复制SELECT
    o.order_id,
    o.amount,
    item_summary.item_count
FROM order o
LEFT JOIN (
    SELECT order_id, COUNT(*) AS item_count
    FROM order_item
    GROUP BY order_id
) item_summary ON item_summary.order_id = o.order_id;

第二种，用 DISTINCT 或子查询去重订单金额再聚合，但写起来复杂，性能也不好。

第三种，在业务侧分开查两次，然后再用代码合并。对于非常复杂的报表，与其在 SQL 里硬拼，不如拆成多条简单 SQL 在应用层组合，逻辑反而更清晰。

我这边实际项目里，凡是出现”订单金额翻倍“类问题时，第一步都是检查 JOIN 是否产生了重复行，第二步再考虑聚合函数怎么写。很多报表数据对不上，不是 SQL 语法问题，而是行数被 JOIN 放大了。

6.3 排序、分组和分页的连带问题

SELECT 里使用 GROUP BY 时，如果 SELECT 列里包含了非聚合字段，MySQL 5.7 之后的默认模式会要求这些字段同时出现在 GROUP BY 中，否则直接报错。比如：

sql复制SELECT u.name, o.order_id, COUNT(*) AS cnt
FROM user u
LEFT JOIN order o ON o.user_id = u.id
GROUP BY u.id;

在 ONLY_FULL_GROUP_BY 开启时，这条 SQL 会报错，因为 o.order_id 没有被 GROUP BY 也没被聚合。解决办法是按 u.id, u.name, o.order_id 全部分组，或者把 o.order_id 包在 MAX(o.order_id) 里。这个问题经常被理解为 MySQL bug，实际上只是 SQL Mode 的约束。

如果 JOIN 之后还要做分页 LIMIT，也要先考虑分页的语义。LIMIT 是对最终结果行数做限制，不是在每个用户的订单里各取几条。如果想实现“每个用户取最近一条订单”，那要用的不是普通 JOIN，而是窗口函数 ROW_NUMBER() OVER(PARTITION BY ...) 或者其他排序取数方案，这一点在面试里也经常考到。

7. 连接查询的性能：索引、驱动表和执行计划

7.1 关联字段不加索引，JOIN 会变成灾难

两表连接时，MySQL 需要拿着驱动表中的每一行关联值去被驱动表里找匹配数据。如果被驱动表的关联字段上没有索引，每次查找都得全表扫描一次。假设 A 表 1 万行，B 表 10 万行，没有索引的情况下可能要执行 1 万次全表扫描，这个代价是难以接受的。

所以连接字段建索引是 JOIN 性能的基础保障。尤其是外键字段，比如 order 表的 user_id，一定记得加索引：

sql复制ALTER TABLE `order` ADD INDEX idx_user_id (user_id);

复合索引也可以考虑。如果查询经常按 user_id 和 status 两个字段一起过滤，那么建立一个 (user_id, status) 的联合索引会比两个独立索引更有效。因为连接匹配时可以先按 user_id 命中，再用 status 进一步过滤，索引能覆盖更多条件。

7.2 用 EXPLAIN 看懂驱动表

MySQL 的优化器会自己决定哪张表作为驱动表，哪张表作为被驱动表。一般来说，它会倾向于用小表驱动大表，也就是小表作为外层循环，大表作为内层循环，让内层表的索引查找次数尽可能少。但这个决定不一定总是最优的，复杂查询时可能会选错执行计划。

用 EXPLAIN 可以查看执行计划：

sql复制EXPLAIN SELECT
    u.name,
    o.order_id
FROM user u
LEFT JOIN order o ON o.user_id = u.id
WHERE u.status = 1;

执行结果里会显示每一行的 type、possible_keys、key、rows 等字段。重点关注 key 是不是 null，如果被驱动表的 key 是 null，说明关联字段索引没生效，要回头检查索引是否建立、字段类型是否一致。

7.3 隐式类型转换会让索引失效

关联字段的类型不一致，是索引失效的常见原因。比如 order 表的 user_id 是字符串类型，user 表的 id 是整数类型：

sql复制SELECT ...
FROM user u
LEFT JOIN order o ON o.user_id = u.id;

MySQL 会把字符串转成数字去比较，这时候 order 表的 user_id 索引可能无法正常使用，查询性能会严重下降。排查方法可以查看字段的字符集和排序规则是否一致、类型是否一致。字符集不一致还要注意乱码问题，比如一张表用 utf8mb4，另一张表用 latin1，连接时也可能触发隐式转换。

7.4 临时表和 filesort 的处理

执行计划里如果出现 Using temporary 或者 Using filesort，通常意味着 GROUP BY 或 ORDER BY 无法直接利用索引完成，MySQL 要生成临时表来排序或分组。大量数据场景下，这会带来严重的磁盘 IO 开销。

优化方向有两个：一个是让 GROUP BY 或 ORDER BY 的字段顺序和索引顺序一致；另一个是尽量少在 JOIN 结果中做 DISTINCT，能提前过滤的条件尽量在子查询里先过滤掉，减少临时表的数据量。

对于非常大的报表查询，如果尝试了各种索引方案效果仍然不理想，我通常会考虑把数据预先汇总成宽表，比如每天跑一个定时任务，把用户维度、订单维度的统计结果写入一张汇总表。业务查询直接查汇总表，性能和稳定性都好很多。这是从“查询优化”走向“数据建模”的思路。

8. 回到实际：连接查询的思考顺序

写连接查询时，我给自己定了三个步骤，分享出来供参考。

第一步想清楚主表是谁，即结果里哪些行必须全部保留。是用户必须全保留，还是订单必须全保留，还是两个都要全保留。这决定了用 LEFT JOIN 还是 FULL JOIN。

第二步想清楚关联条件，即两张表通过哪个字段对应。条件里要不要加额外的状态限制，如果要加，那么这些限制是放在 ON 里还是 WHERE 里。放错位置会导致结果行数和预期不一致。

第三步想清楚聚合和去重，特别是 JOIN 后行数有没有放大，COUNT 和 SUM 会不会重复计算。多表聚合之前先跑一条不带 GROUP BY 的查询，肉眼观察一下行数和明细是否符合预期，再写聚合 SQL。这是我最常做也最推荐做的验证动作。

连接查询不是用来炫技的，它的本质是数据建模思维的落地。搞清楚每张表的粒度、主外键关系、保留规则，写出来的 SQL 才经得起推敲。从内连到外连，语法差别不大，但每一步背后都对应着明确的业务语义，这才是真正值钱的部分。