MySQL复合查询详解：JOIN、子查询与UNION实战指南

如果说 MySQL 学习有一个分水岭，很多人会告诉你是从单表查询过渡到多表查询的那一刻。单表 SELECT、WHERE、GROUP BY 都写得很顺，一旦遇到“订单和用户要一起查”、“找出没买过东西的客户”、“把每个月的数据拼在一起展示”这类需求，就容易卡壳。我在整理 MySQL 系列笔记时，第 10 篇正好落在“复合查询”这一块，今天就把这块内容拆开聊透。

这篇笔记解决的核心问题只有一个：数据分散在多张表时，如何用一条 SQL 把需要的信息重新组合出来。复合查询本身并不神秘，本质是三类操作的组合——连接查询（JOIN）、子查询、集合查询（UNION）。如果你是刚学完基础 SQL 的初学者，或者准备面试时对多表查询总有一种“会写但不敢确定对不对”的感觉，这篇文章可以直接解决你的疑惑。我会先讲清楚每类查询的适用场景，再用一个学生成绩管理系统的完整案例串起来，最后给出一份日常排错速查表。

1. 复合查询是什么：什么样的需求会用到它

1.1 先理解“单表查询为什么不够”

数据库设计时有一个基本思路叫范式化，简单说就是把数据拆开存放，避免冗余。比如订单表里不会存客户姓名，只会存一个 customer_id；商品表不会存供应商地址，只存 supplier_id。这样做的好处是更新数据时只需改一处，不会出现同一份信息在不同表里对不上的情况，但代价就是查询时需要把拆开的表再拼回来。

举一个现实中的例子。你打开外卖 App 查看历史订单，页面同时需要展示订单号、商品名称、店铺名、支付金额、收货地址。这些字段分散在订单表、店铺表、商品表里，单表查询无论怎么查都拿不全。唯一的方法是把多张表按照外键关系连起来，一次查出完整的一行宽表，这就是复合查询存在的价值。

很多人刚接触这个概念时容易把“复合查询”等同于“多表 JOIN”，其实这样理解偏窄了。JOIN 只是其中一种手段，复合查询还包含子查询和 UNION。之所以需要三种方式而不是一种万能方案，是因为业务问题天然分成不同类型：有些需求是横向补充字段，有些是纵向叠加行数，有些是一个查询结果要作为另一个查询的条件。搞清楚这个分类，选型就不会乱。

1.2 复合查询的三种形态与选型直觉

我把常见需求归纳成一张直觉对照表，后面详细展开，先给大家一个整体图景：

选择时只需问自己一个问题：结果集是变“宽”了，还是变“长”了？变宽用 JOIN，变长用 UNION，拿不准或者需要分步计算时用子查询。实际业务里三种方式经常嵌套使用，所以我会在后面的实战部分把组合场景一起演示。

2. 连接查询：JOIN 的核心逻辑和最容易踩的坑

2.1 各类 JOIN 一句话说清

JOIN 本身有几种类型，初学者最容易被 LEFT JOIN、RIGHT JOIN、INNER JOIN 绕晕。我在给团队新人培训时，通常先用两张小表把语义讲明白。假设 customer 表有 4 个客户，orders 表只有 3 条订单，其中一条订单的 customer_id 关联不上。

sql复制-- 建两张演示表
CREATE TABLE customer (
  id INT PRIMARY KEY,
  name VARCHAR(20)
);

CREATE TABLE orders (
  id INT PRIMARY KEY,
  customer_id INT,
  amount INT
);

INSERT INTO customer VALUES (1, '张三'), (2, '李四'), (3, '王五'), (4, '赵六');
INSERT INTO orders VALUES (101, 1, 200), (102, 1, 350), (103, 2, 120);

INNER JOIN 返回两表都匹配上的行，也就是只在两表“交集”中取数据：

sql复制SELECT c.name, o.id AS order_id, o.amount
FROM customer c
INNER JOIN orders o ON c.id = o.customer_id;

结果只有张三有两条订单、李四有一条。王五和赵六没有订单，不会出现。这就是内连接，适合查询“必须有对应关系”的数据，比如既有客户又确实下了单的记录。

LEFT JOIN 的左表是 customer，它要求左表全部保留。右表能匹配就返回订单信息，匹配不上就用 NULL 补齐：

sql复制SELECT c.name, o.id AS order_id, o.amount
FROM customer c
LEFT JOIN orders o ON c.id = o.customer_id;

结果会包含王五和赵六，但他们 order_id 和 amount 字段是 NULL。这个语义非常关键，适合“以某张表为主线，看它在另一张表是否存在对应记录”的需求。RIGHT JOIN 逻辑完全对称，只是主表换成了右表。实际工作中我很少用 RIGHT JOIN，因为把主表写在左边语义更直观，也方便后续维护。

FROM 后面的表可以多次出现同一个物理表，这叫自连接。员工表里存了 manager_id，要查出每个员工对应的上级姓名时，就需要把同一张表当作两张表来连接：

sql复制SELECT e.name AS employee_name, m.name AS manager_name
FROM employee e
LEFT JOIN employee m ON e.manager_id = m.id;

自连接不是特殊语法，只是连接思路的延伸。只要心里清楚“我把这张表复制了一份，只是起了不同别名”，写起来就不会晕。

2.2 ON 与 WHERE 的执行时机差异

这是我见过翻车率最高的一个点。很多人在 LEFT JOIN 之后习惯性把过滤条件写在 WHERE 里，结果左表本该保留的行莫名其妙消失了。

用刚才客户和订单的例子，我想查“下单金额超过 150 元的客户，同时保留没有下单的客户”。如果写成：

sql复制SELECT c.name, o.id AS order_id, o.amount
FROM customer c
LEFT JOIN orders o ON c.id = o.customer_id
WHERE o.amount > 150;

这条 SQL 的执行逻辑是：先按 ON 条件做 LEFT JOIN，生成一张包含 NULL 的中间结果表；然后进入 WHERE 过滤阶段。这一阶段里，所有没有匹配订单的客户行，其 o.amount 都是 NULL。NULL 和 150 做比较时结果不是 FALSE，而是 UNKNOWN，会被 WHERE 过滤掉。于是王五、赵六这些“没下过单的客户”全部消失，你得到的实际是 INNER JOIN 的结果。

正确的做法是把过滤条件放到 ON 子句中：

sql复制SELECT c.name, o.id AS order_id, o.amount
FROM customer c
LEFT JOIN orders o ON c.id = o.customer_id AND o.amount > 150;

ON 里的条件决定右表如何与左表匹配。订单金额不满足 150 的行会被当作“匹配失败”，右表字段补 NULL，左表行依然保留。

这个细节必须从执行顺序上理解：JOIN 的 ON 先执行，WHERE 后执行。写出 LEFT JOIN 时，心里默认的意图往往是“左表行不能丢”，那么凡是会影响右表是否匹配的条件，尽量放 ON；凡是针对整行结果的最终过滤，才放 WHERE。我见过不少线上报表因为这里写错，导致“无数据客户”被漏统计，问题排查起来又慢又隐蔽。

2.3 自连接与多表连接的驱动表问题

三张表以上连接时，MySQL 优化器会决定先连接哪两张、以哪张表作为驱动表。对于 INNER JOIN，优化器通常会基于成本选择结果集较小的表作为驱动表；对于 LEFT JOIN，驱动表基本固定为左表。

驱动表的选择为什么重要？因为连接查询可以理解为“从驱动表取一行，去另一张表里找匹配行”。如果被驱动表的连接列有索引，查找速度会快很多。反过来如果连接列没索引，MySQL 就得对被驱动表做全表扫描，性能会断崖式下降。

我在实际项目里见过一个典型问题：订单表几百万行，用户表几千行，有人写 JOIN 时习惯把大表当左表，结果 WHERE 条件只过滤用户表，优化器没选出正确的驱动表，执行时间从几十毫秒涨到几十秒。解决办法很简单，先尽量把过滤后数据量小的表放左侧，再通过 EXPLAIN 观察执行计划，必要时调整条件写法或增加索引。这部分我在第 6 章会专门演示怎么用 EXPLAIN 判断连接顺序是否合理。

3. 子查询：三种位置、两种语气、一个关键坑

3.1 WHERE 子查询：IN / EXISTS 怎么选

子查询最常用的位置是 WHERE 条件中。它的作用是把一个查询结果作为外层查询的判断条件。比如要查“买过键盘的客户”，可以先查订单表里包含键盘的 customer_id 集合，再用外层查询从客户表里筛人：

sql复制SELECT name
FROM customer
WHERE id IN (
  SELECT customer_id
  FROM orders
  WHERE product_name = '键盘'
);

IN 适合子查询结果集比较小、且确定不会有 NULL 值干扰的场景。和它功能接近的是 EXISTS：

sql复制SELECT name
FROM customer c
WHERE EXISTS (
  SELECT 1
  FROM orders o
  WHERE o.customer_id = c.id
    AND o.amount > 500
);

EXISTS 是一种“相关子查询”，外层每处理一行，子查询就要根据当前行的值去判断一次。它关注的是“是否存在满足条件的记录”，而不是返回具体什么值，所以子查询里写 SELECT 1 即可，没人关心实际列内容。

网上流传着“IN 慢 EXISTS 快”的说法，这在 MySQL 5.6 之前有一定道理，5.6 之后优化器会把很多 IN 改写为 semi-join，两者性能差距没有想象中那么大。我的建议是不要背结论，而是从语义出发：核心是判断“集合成员关系”时用 IN，核心是判断“是否存在关联记录”时用 EXISTS，拿不准就 EXPLAIN 看执行计划。

3.2 FROM 子查询与 SELECT 子查询

子查询也可以放在 FROM 后面，充当一张临时生成的表，业内叫派生表。最典型的场景是“先聚合，再对聚合结果过滤”。SQL 语法规定 WHERE 后不能直接使用聚合函数，比如你想找出平均工资超过 8000 的部门：

sql复制SELECT dept_id, avg_salary
FROM (
  SELECT dept_id, AVG(salary) AS avg_salary
  FROM employee
  GROUP BY dept_id
) AS dept_stat
WHERE avg_salary > 8000;

这里内层先完成部门平均工资计算，外层再对结果过滤。注意 AS dept_stat 这个别名不能少，MySQL 要求派生表必须有一个别名，否则直接报语法错误。

SELECT 子查询也叫标量子查询，它要求返回一行一列，可以像普通字段一样展示。比如展示每个员工的薪资和公司平均薪资的差距：

sql复制SELECT name, salary,
       (SELECT AVG(salary) FROM employee) AS company_avg,
       salary - (SELECT AVG(salary) FROM employee) AS diff
FROM employee;

这个写法直观，但需要留个心眼：如果子查询返回多行，MySQL 会报 ERROR 1242 Subquery returns more than 1 row；如果返回多列，语法上就不被允许。相关子查询还有个特点，外层每处理一行，内层就可能执行一次，数据量大时开销不可忽视。遇到这种需求我更建议先用 JOIN + GROUP BY 算平均值，再连接回员工表，可读性和性能通常更好。

3.3 NOT IN 与 NULL 的必踩坑

如果只记一个子查询坑，那一定是 NOT IN 遇到 NULL。看这条查询：

sql复制SELECT name
FROM customer
WHERE id NOT IN (
  SELECT customer_id
  FROM orders
);

假设 orders 表里有一条脏数据，customer_id 为 NULL。此时子查询的结果集合是 {1, 2, NULL}。SQL 中 NULL 参与比较会产生 UNKNOWN 而不是明确的 TRUE/FALSE。对任意一个客户 ID，比如 3，判断 3 NOT IN (1, 2, NULL)，等于判断 3 != 1 且 3 != 2 且 3 != NULL。最后一个比较结果是 UNKNOWN，整个 AND 的结果就是 UNKNOWN，WHERE 只保留 TRUE，于是这行被过滤掉。最终结果就是查询返回空，或者只返回少量行，完全不符合直觉。

解决方案是避开 NOT IN，改用 NOT EXISTS：

sql复制SELECT name
FROM customer c
WHERE NOT EXISTS (
  SELECT 1
  FROM orders o
  WHERE o.customer_id = c.id
);

NOT EXISTS 的判断方式不同，它只看能否找到匹配行，不会因为 NULL 而“搅局”。这个坑在真实数据环境里非常常见，订单表、日志表经常存在外键为 NULL 的数据，用 NOT IN 查“没有对应记录”的名单时，结果一旦为空，首先要怀疑的除了逻辑本身还有 NULL。

4. UNION 联合查询：把结果集纵向拼起来

4.1 UNION 与 UNION ALL 的实际差异

当多个查询结果结构相同，需要上下拼接展示时，就该 UNION 出场。比如公司有两个销售团队，各自的数据存在不同的表里，要看全公司总业绩，就把两段 SELECT 拼起来：

sql复制SELECT sales_name, amount FROM team_a_sales
UNION ALL
SELECT sales_name, amount FROM team_b_sales;

UNION 和 UNION ALL 的区别只有一个：UNION 会对合并后的结果做去重，UNION ALL 则原样拼接。去重听起来更“干净”，但代价是需要对结果排序或建立哈希表来识别重复行，内存和耗时都会增加。实际开发中除非明确要求去重，否则我默认用 UNION ALL。因为大部分业务数据本身没有重复，或者重复也无所谓，白花去重开销不划算。

判断“重复”的依据是所有列的值都相同。如果两个 SELECT 只是部分字段一样，其他字段不同，UNION 不会把它们合并。

4.2 排序、去重与列匹配的边界问题

UNION 使用中有几个边界条件经常让新手措手不及。第一，各 SELECT 语句的列数必须一致；第二，列类型最好兼容，MySQL 虽然会自动做隐式转换，但可能出现不可预期的结果；第三，最终结果集的列名以第一个 SELECT 为准。

排序尤其容易写错。很多人想对每个子查询先排序再合并，会写出这样的 SQL：

sql复制SELECT id, amount FROM sales_jan ORDER BY amount DESC
UNION ALL
SELECT id, amount FROM sales_feb ORDER BY amount DESC;

这种写法从 MySQL 8.0.19 之后语法上可能不会直接报错，但行为并不符合直觉，而且在不同版本表现不一致。正确做法是让排序作用于整个 UNION 结果，把 ORDER BY 放在最后：

sql复制SELECT id, amount, 'jan' AS source FROM sales_jan
UNION ALL
SELECT id, amount, 'feb' AS source FROM sales_feb
ORDER BY amount DESC;

如果想保留“每个子查询各自排好序、拼接后顺序不被打乱”，单靠 ORDER BY 很难保证，因为这些子查询数据合在一起没有天然的组内边界。一个稳妥办法是额外加一列分组标识，整体排序时先按分组排，再按分组内顺序排。这种需求往往是想做“多个班级各自排名再汇总展示”，用窗口函数会更清晰。

4.3 用 UNION 实现简易行转列

聊到 UNION，顺便说一个常被搜索的实际场景：行转列。虽然标准的行转列更常用 CASE WHEN + GROUP BY，但 UNION 也可以完成简单的转换，区别在于它是把“每个分类”单独查成一行，再把多行结果拼起来。

成绩表里存了每个学生的多门课程分数，要转成一行一列一个课程的宽表，习惯做法是先查出每个学生的语文成绩，再查出数学成绩，最后纵向连接：

sql复制SELECT student_id, '语文' AS course, score FROM score WHERE course_id = 1
UNION ALL
SELECT student_id, '数学', score FROM score WHERE course_id = 2
UNION ALL
SELECT student_id, '英语', score FROM score WHERE course_id = 3;

这种写法胜在容易理解，缺点是需要手动枚举课程。真正的行转列还是推荐用分组 + 条件聚合一次完成，第 5 章的实战会演示完整写法。

5. 完整实战：学生成绩管理系统的复合查询

5.1 表结构与演示数据准备

理论讲了这么多，还是要落到能跑的 SQL 上。下面用一套学生成绩管理系统的经典结构，演示 JOIN、子查询、UNION 如何协同工作。

sql复制CREATE TABLE student (
  id INT PRIMARY KEY AUTO_INCREMENT,
  name VARCHAR(20) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE course (
  id INT PRIMARY KEY AUTO_INCREMENT,
  course_name VARCHAR(50) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE score (
  id INT PRIMARY KEY AUTO_INCREMENT,
  student_id INT NOT NULL,
  course_id INT NOT NULL,
  score DECIMAL(5,1) NOT NULL,
  UNIQUE KEY uk_stu_course (student_id, course_id),
  CONSTRAINT fk_score_student FOREIGN KEY (student_id) REFERENCES student(id),
  CONSTRAINT fk_score_course FOREIGN KEY (course_id) REFERENCES course(id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

插入演示数据，我刻意安排了四类典型数据：张三成绩全面，李四有一门挂科，王五有两门挂科，赵六完全没选课。

sql复制INSERT INTO student (name) VALUES
('张三'), ('李四'), ('王五'), ('赵六');

INSERT INTO course (course_name) VALUES
('数据库原理'), ('计算机网络'), ('数据结构'), ('高等数学'), ('大学英语');

INSERT INTO score (student_id, course_id, score) VALUES
(1, 1, 88.0), (1, 2, 76.0), (1, 3, 95.0),
(2, 2, 92.0), (2, 4, 55.0), (2, 5, 69.0),
(3, 1, 78.0), (3, 2, 52.0), (3, 3, 82.0), (3, 4, 58.0), (3, 5, 90.0);

赵六的 student_id 是 4，score 表里没有任何记录。

5.2 需求一：查询每个学生的选课数量与平均分

这个需求看起来简单，但它能一次性考察 LEFT JOIN、GROUP BY、COUNT、AVG 四个知识点。

sql复制SELECT
  s.id,
  s.name,
  COUNT(sc.id) AS course_count,
  ROUND(AVG(sc.score), 1) AS avg_score
FROM student s
LEFT JOIN score sc ON sc.student_id = s.id
GROUP BY s.id, s.name;

先看结果（MySQL 客户端可能显示多条记录）：

text复制id   name   course_count   avg_score
1    张三   3             86.3
2    李四   3             72.0
3    王五   5             72.0
4    赵六   0             NULL

这里有两个关键点。为什么用 LEFT JOIN 而不是 JOIN？因为赵六没有选课记录，如果用 INNER JOIN，他会被直接过滤掉，“每个学生”的需求就不成立了。为什么 COUNT 的是 sc.id 而不是 COUNT()? 因为 COUNT() 会对分组内所有行计数，赵六那组虽然 sc 部分全是 NULL，但仍会算作一行，course_count 就会错成 1。而 COUNT(sc.id) 只统计非 NULL 的列值，赵六没有成绩行，sc.id 为 NULL，所以正确显示 0。

这是我面试候选人时经常问的细节。很多人写得出 JOIN，但搞不清楚什么时候该用 COUNT(具体字段)、什么时候该用 COUNT(*)，从而产生“多出一条 NULL 记录”的诡异结果。

5.3 需求二：查询每门课程最高分及其得分学生

这个需求比上一个复杂很多，因为要先求每门课的最高分，再回过头来找这个分数对应的是哪位学生。我给出的标准写法是两层子查询 + 两次 JOIN：

sql复制SELECT
  c.course_name,
  s.name AS student_name,
  t.max_score
FROM course c
JOIN (
  SELECT course_id, MAX(score) AS max_score
  FROM score
  GROUP BY course_id
) t ON t.course_id = c.id
JOIN score sc ON sc.course_id = t.course_id AND sc.score = t.max_score
JOIN student s ON s.id = sc.student_id
ORDER BY c.id;

这种写法逻辑分层很清楚：首先内层子查询算出每个 course_id 的最高分；然后把它当作一张临时表和 course 连接，得到课程名；再和 score 连接，条件是“同课程且分数等于最高分”，这样定位到具体成绩记录；最后连接 student 拿到姓名。如果一门课有两个人并列最高，这个查询会返回两行，符合业务直觉。

新手最容易写错的做法是直接 GROUP BY：

sql复制SELECT course_id, MAX(score), student_id
FROM score
GROUP BY course_id;

在 MySQL 的 ONLY_FULL_GROUP_BY 模式下，这条 SQL 直接报 ERROR 1055，因为 student_id 既没有出现在 GROUP BY 里，也没有被聚合函数包裹。就算把 SQL_MODE 改宽松能跑出结果，返回的 student_id 也未必是最高分那个学生，而是“该组内的任意值”，这是完全不可控的。遇到“分组后取每组某条件下的明细”类需求，思路要立刻切换到 JOIN 或窗口函数，而不是硬 GROUP BY。

5.4 需求三：统计“至少两门不及格”的学生

首先解释“不及格”的判定：score 小于 60。要统计每个学生有几门不及格，应该用 WHERE 把低于 60 的记录筛出来，再按学生分组计数，最后用 HAVING 过滤分组后的结果。

sql复制SELECT
  s.name,
  COUNT(*) AS fail_course_count
FROM score sc
JOIN student s ON s.id = sc.student_id
WHERE sc.score < 60
GROUP BY s.id, s.name
HAVING COUNT(*) >= 2;

这个查询用 INNER JOIN 没有问题，因为能被统计到的学生必然有成绩记录。筛选逻辑放在 WHERE 里，分组和筛选分组放在 HAVING 里。结果应当只有王五，因为李四只有数学 55 分不及格，王五的计算机网络 52 分和高等数学 58 分都不及格。

这里解释一下为什么 WHERE 和 HAVING 不能互换。WHERE 是在分组前对原始行做过滤，HAVING 是在分组聚合后对聚合结果做过滤。如果尝试写 WHERE COUNT(*) >= 2，MySQL 会直接报语法错误，因为 WHERE 子句执行时分组还没发生，聚合函数无从谈起。

5.5 需求四：输出学生各科成绩横向表

最后做一个行转列。目标是把成绩表从纵向的“一个学生多条课程记录”变成横向的“一行一个学生、每门课占一列”。核心技巧是固定课程列表 + 条件聚合。

sql复制SELECT
  s.name AS 姓名,
  MAX(CASE WHEN c.course_name = '数据库原理' THEN sc.score END) AS 数据库原理,
  MAX(CASE WHEN c.course_name = '计算机网络' THEN sc.score END) AS 计算机网络,
  MAX(CASE WHEN c.course_name = '数据结构' THEN sc.score END) AS 数据结构,
  MAX(CASE WHEN c.course_name = '高等数学' THEN sc.score END) AS 高等数学,
  MAX(CASE WHEN c.course_name = '大学英语' THEN sc.score END) AS 大学英语
FROM student s
LEFT JOIN score sc ON sc.student_id = s.id
LEFT JOIN course c ON c.id = sc.course_id
GROUP BY s.id, s.name;

为什么 CASE WHEN 外面套 MAX？因为 GROUP BY s.id 之后，每个学生可能有多行课程成绩，如果不套聚合函数，该字段的值无法确定取哪一行。当某学生没有选某门课时，CASE WHEN 不满足条件，返回 NULL，MAX 只取非 NULL 值，所以不会干扰其他课程。

赵六一行全为 NULL，表示他没有任何成绩，这样报表依然可以保留所有学生，比只统计有成绩的学生更完整。热词里经常被搜的“mysql 行转列”，本质上就是这种 GROUP BY + CASE WHEN + 聚合函数的组合。

6. 复合查询性能观察与 EXPLAIN 实战

6.1 先看执行计划：几个关键字段

SQL 写得对不对只是第一步，跑得快不快是另一回事。MySQL 里用 EXPLAIN 前缀就可以看到优化器生成的执行计划：

sql复制EXPLAIN SELECT s.name, sc.score
FROM student s
LEFT JOIN score sc ON sc.student_id = s.id;

输出结果是一张表，我主要关注四列：

type 字段从好到差通常可以理解为 system、const、eq_ref、ref、range、index、ALL 的递减趋势。连接查询中理想情况是用到 eq_ref 或 ref，意味着被驱动表通过主键或唯一索引查找；如果看到 type=ALL 且 rows 很大，基本可以判定这里缺少索引或连接条件写得不合适。

6.2 连接顺序与索引利用

回到第 5 章的 student LEFT JOIN score 示例。student 表只有 4 行，score 表 11 行，即使全表扫描也没压力。但真实业务中如果有 10 万学生、500 万成绩记录，连接条件就必须有索引。score 表的外键 student_id 上如果没有索引，MySQL 每从 student 取一行，就要在 score 里扫一遍全表找匹配，那实际成本就是 10 万乘以 500 万，瞬间崩溃。

我给成绩表加上复合索引：

sql复制ALTER TABLE score ADD INDEX idx_student_course (student_id, course_id);

再次 EXPLAIN，能看到 score 表的 type 变成 ref，key 显示 idx_student_course，rows 明显下降。这种“小表驱动大表 + 大表连接列有索引”的组合，是复合查询性能的基本盘。额外提醒一句，索引不是越多越好，每次写入都要维护索引，精确分析业务查询后再加才是正道。

6.3 子查询的物化与派生表合并

MySQL 5.7 之后对子查询做了很多优化。派生表可能被优化器合并到外层查询，也可能被“物化”成一张临时表。看执行计划时，如果 select_type 为 DERIVED，说明派生表被物化；如果外层查询的派生表出现在 JOIN 区域且没有 DERIVED 标识，说明优化器做了合并。两种方式各有优劣，不必强行干预。真正要避免的是自己在子查询里写不必要的 DISTINCT、ORDER BY，这些操作会在物化过程中引入额外排序和去重成本。

还有一个经常被忽视的点：查询结果需要分页时，尽量避免“大偏移量 + 多表 JOIN”组合。比如 LIMIT 1000000, 20，MySQL 要先扫描出一百万行再丢掉，开销很高。常见优化是先用覆盖索引查出目标主键，再回表 join：

sql复制SELECT s.name, sc.score
FROM student s
JOIN score sc ON sc.student_id = s.id
WHERE s.id IN (
  SELECT id
  FROM student
  ORDER BY id
  LIMIT 1000000, 20
);

这个技巧叫延迟关联，本质是让最耗时的 LIMIT 只发生在一张小结果集上，能明显改善深分页场景。

7. 复合查询常见报错与排查速查

7.1 高频报错整理

我整理了复合查询中最常出现的几类报错，每一条都在实际工作中遇到并解决过。

7.2 多表查询结果变多/变少的排查思路

结果集数量不符合预期，绝大多数不是 SQL 语法问题，而是连接粒度问题。连接粒度简单说就是“一对多”会被放大成“多对多”。订单表和订单明细表按订单号连接，如果一个订单有三条明细，连接后的结果就会有三行，订单表的主信息被重复三次。这时候统计订单数量若直接 COUNT(*)，会得到明细数量而不是订单数量。

排查这类问题有一套固定思路。第一步，分别查各个基础表的行数，确定哪张表是多方。第二步，把 JOIN 去掉，单独查最关心的主表数据量，看是否一致。第三步，如果确认是多方导致放大，选择先聚合多方。比如先统计每个订单的明细数量：

sql复制SELECT order_id, COUNT(*) AS item_count
FROM order_item
GROUP BY order_id;

再把聚合结果作为派生表 JOIN 回订单表，就不会产生行数放大。最后再用 COUNT(DISTINCT 主表主键) 做交叉验证，能快速判断结果是否可信。

结果变少则优先检查 JOIN 类型和过滤条件位置。只要使用了 INNER JOIN，任何一个表存在不匹配的数据就会减少结果；只要 WHERE 里写了对被驱动表字段的过滤，LEFT JOIN 也很可能退化成 INNER JOIN。这两个方向查完，基本能覆盖 90% 的异常场景。

多表复合查询本身并不复杂，复杂的是对表关系的理解和对 SQL 执行顺序的把控。我个人带新人的时候，最常用的一套练习方法是：不要死记硬背所谓的七种 JOIN，而是拿两三张有真实外键关联的表反复执行 EXPLAIN，观察 ON 条件变化、WHERE 条件变化对结果行数和执行计划的影响。多练几次之后你会发现，面试里那些关于复合查询的问题，本质上都是在考察你有没有真正理解“数据怎么被组合起来”这件事。如果这篇内容对你有帮助，建议把文中的建表语句和四个需求从头到尾亲手跑一遍，踩一踩 NULL 和 GROUP BY 的坑，比看十遍理论都管用。