数据库玩到一定阶段，单表查询已经满足不了业务需求了。你迟早会遇到两种场景：一是要把同一组数据“折叠”成一个汇总值，比如统计每个月的订单总额、各部门平均薪资；二是要把多张表的信息拼在一起看，比如查订单的同时带出客户姓名和商品名称。这两个场景分别对应聚合查询和联合查询，也是面试中被问烂、实际开发中却最容易写错的SQL。
我见过太多人，单表SELECT、WHERE用得飞起，一碰GROUP BY就报错，一写JOIN就晕头转向。归根结底，是没有理解聚合查询和联合查询的底层逻辑，只记住了语法皮毛。这篇内容我打算把这两块一次性讲透，包括聚合函数怎么用、GROUP BY的分组原理、内连接与外连接的差异、以及聚合和连接叠加在一起时那些容易翻车的细节。无论你是刚学MySQL的新手，还是写了两三年SQL但没系统梳理过查询逻辑的开发者，这篇文章都能给你一个相对完整的视角。
1. 聚合查询与group by的设计思路
1.1 为什么要有多行“压”成一行
先看一个最朴素的场景。你维护了一张订单表，里面有客户、金额、下单时间。老板说：给我算一下这个月总共卖了多少。你脑子里第一个反应可能是把数据全捞出来，然后在Java、Python或者Excel里加总。这当然能跑，但数据量一大就不行了——十万行数据传到应用层再求和，网络开销和时间成本都很高。
数据库本身就是为了处理这类“批量计算”而生的。聚合查询就是把多行数据按照某个规则归并，然后计算出一个结果，这个过程全部在数据库内部完成。核心组件就是聚合函数：
- COUNT()：数行数
- SUM()：求和
- AVG()：求平均值
- MAX() / MIN()：求最大/最小值
这些函数的共同特点，是“输入多行，输出一行”。这叫多行输入单行输出，和普通函数的“单行输入单行输出”有本质区别。你要算一天的总销售额，一条SQL就能搞定：
SELECT SUM(amount) AS total_amount FROM orders WHERE order_date = '2024-11-20';这里没有GROUP BY，所有命中的行被当成一个整体，SUM把amount列的值全部加总，输出一行。这就是最简单的聚合查询。
1.2 group by到底在做什么
要是需求变成“统计每位客户的消费总额”呢？你不能再把全部行当一个整体了，得按照客户维度拆成多组，每组各自算一个总和。这时GROUP BY就登场了。
GROUP BY的语义可以这样理解：把表中所有行按照指定列的值“分组”，值相同的行归到一个桶里。每个桶输出一行结果。比如下面这句：
SELECT customer_id, SUM(amount) AS total_amount FROM orders GROUP BY customer_id;orders表里有几个不同的customer_id，最终就输出几行。每一行代表一个客户，以及这个客户所有订单金额的总和。
这里有一个新手最容易踩的规则：SELECT后面能出现的列，要么是GROUP BY里写过的列，要么是被聚合函数包裹的列。其他列出现在SELECT里，严格模式下直接报错，宽松模式下也会得出一个没有任何意义的值。
这是为什么？因为分组之后，一个桶里有多行，如果你SELECT一个既不在分组键里、也没被聚合函数处理的列，数据库根本不知道应该取出哪一行。它只能随机挑一个给你，这个结果既不准确也不可复现。
1.3 分组前过滤和分组后过滤
写聚合查询的时候，经常会混淆WHERE和HAVING。一句话记住两者的区别：WHERE是在分组之前过滤原始行，HAVING是在分组之后过滤结果组。
比如你要统计“2024年每个客户的消费总额，并且只要消费总额超过1000的客户”。第一步得先过滤出2024年的订单（原始行），然后按客户分组，最后过滤掉总额不足1000的组：
SELECT customer_id, SUM(amount) AS total_amount FROM orders WHERE order_date BETWEEN '2024-01-01' AND '2024-12-31' GROUP BY customer_id HAVING total_amount > 1000;注意，WHERE里不能使用聚合函数，因为聚合发生在WHERE之后，WHERE执行时还没有聚合结果可用。而HAVING可以，因为它发生在分组和聚合之后，此时SUM的结果已经算出来了。
这条规则背后的执行顺序是：
FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY → LIMIT理解执行顺序非常重要。它能解释很多奇怪的现象——比如为什么WHERE里不能用列别名（别名在SELECT阶段才生成），为什么HAVING里能引用聚合函数，为什么ORDER BY里又能用别名了。
2. 核心细节解析与实操要点
2.1 聚合函数的高频陷阱
聚合函数看着简单，用起来坑不少。先说COUNT。它有几种写法，语义各不相同：
SELECT COUNT(*) FROM orders; SELECT COUNT(1) FROM orders; SELECT COUNT(customer_id) FROM orders;COUNT(*)和COUNT(1)都表示“统计表中的总行数”，效果完全一样，性能差异在绝大多数场景下可以忽略，选哪个纯看个人习惯。但COUNT(customer_id)不一样——它统计的是customer_id列非NULL的行数。如果某一行customer_id是NULL，这一行不会被计数。
我曾见过一个线上问题：业务方统计订单总量，用的是COUNT(order_no)，结果发现order_no字段在某些历史数据里是NULL，统计出来的数字比实际订单行数少了几十条。排查半天才发现是NULL值在作怪。所以，COUNT一个具体的列之前，一定要先想清楚这个列是否可能为NULL。
SUM和AVG同样受NULL影响。SUM在遇到NULL时会跳过该行的值，AVG在计算平均值时也会剔除NULL行。但有一个反直觉的地方：如果整组数据全是NULL，SUM返回的是NULL而不是0。这会导致外层计算做加法时结果莫名其妙变成NULL。处理方式是使用IFNULL或COALESCE包一层：
SELECT customer_id, IFNULL(SUM(amount), 0) AS total_amount FROM orders GROUP BY customer_id;MAX和MIN没有NULL问题，它们天然忽略NULL，对字符串类型也能按字典序取最大最小。比如查找字母表里最靠后的客户名，用MAX(customer_name)就行。
2.2 多列分组的使用技巧
GROUP BY后面可以跟多个列，它的逻辑是“先用第一列分组，然后在第一列相同的组里，再按第二列分组”。相当于建立了一个多级桶结构。
举个例子。你的订单表里有customer_id和order_status两个字段。你想统计“每个客户、每种状态分别有多少订单”：
SELECT customer_id, order_status, COUNT(*) AS order_count FROM orders GROUP BY customer_id, order_status;输出的每一行代表某个客户在某个状态下的订单数。两个分组键的值的组合构成唯一标识。
多列分组时要注意列的先后顺序对结果没有影响（最终分组结果一样），但对索引利用率和排序可能有影响。如果后续要配合ORDER BY，可以考虑让GROUP BY的列顺序和ORDER BY一致，减少一次文件排序。
2.3 聚合查询常用场景速查
| 场景需求 | 聚合函数/写法 | 说明 |
|---|---|---|
| 统计总行数 | COUNT(*) | 不关心具体哪一列，直接数行 |
| 统计非空值个数 | COUNT(column) | 忽略NULL行，适用于统计有值记录 |
| 求和 | SUM(column) | 忽略NULL，全NULL返回NULL |
| 平均 | AVG(column) | 忽略NULL，等同于SUM/COUNT（非空行数） |
| 最大/最小 | MAX(column) / MIN(column) | 忽略NULL，数字、日期、字符串均适用 |
| 分组后过滤 | HAVING | 与WHERE等价，但作用于分组后的结果 |
| 去除重复后再计数 | COUNT(DISTINCT column) | 常用于统计不同用户数、不同商品数 |
这里面最后一行特别值得注意。统计“有多少个不同客户下单”，不能直接COUNT(customer_id)，因为一个客户可能下多单，会被重复计数。正确写法是COUNT(DISTINCT customer_id)。这个差异在报表统计中极其常见，也是面试必考题。
3. 联合查询：内连接与外连接的原理与实现
3.1 先说底层：连接查询的“老母鸡”——笛卡尔积
聚合查询解决的是“把多行算成一行”，联合查询解决的是“把两张表拼成一张大表”。要理解JOIN，先要理解笛卡尔积。
什么是笛卡尔积？假设员工表有3行，部门表有4行，那么这两张表做笛卡尔积会得到3×4=12行——每一行员工都会和每一行部门拼接一次，形成一个“组合”。这种组合绝大多数是没有意义且错误的。
连接查询做的事情，本质上就是：先生成笛卡尔积，然后用连接条件过滤掉无意义的组合，只保留符合关联关系的行。
所以写JOIN时，ON条件的正确与否直接决定结果正确与否。关联字段选错了，或者漏了关联条件，结果就会变成笛卡尔积爆炸——数据量一大，一条SQL直接把数据库拖垮。
3.2 内连接：只要匹配上的“交集”
内连接（INNER JOIN）的语义是：只返回左右两表中满足连接条件的行。左侧表有匹配就返回，右侧表有匹配也有，不匹配的直接丢弃。
看一个经典的员工和部门例子。员工表employee里有部门编号dept_id，部门表department里有部门编号id。要查每个员工的名字和所在部门名称：
SELECT e.emp_name, d.dept_name FROM employee e INNER JOIN department d ON e.dept_id = d.id;这里用了别名e和d，是给表起简称，简化书写。结果里不会出现“没有部门”的员工，也不会出现“没有员工”的部门，因为任何一边缺少匹配，整行就被丢弃。
内连接的另一种等价写法是直接把连接条件放在WHERE里：
SELECT e.emp_name, d.dept_name FROM employee e, department d WHERE e.dept_id = d.id;两种写法执行计划在MySQL优化器层面通常是等价的，但从可读性和维护性角度，我推荐使用INNER JOIN ... ON这种现代写法，连接条件和过滤条件分离，逻辑更清楚。
3.3 外连接：保留“另一边”的三种姿势
外连接的核心思想是：保留一边的全部数据，另一边没有匹配就补NULL。
左外连接（LEFT JOIN）：返回左表全部行。右表有匹配的行正常拼接，没有匹配的行用NULL填充右表所有列。右外连接（RIGHT JOIN）则相反，返回右表全部行，左表没有匹配的补NULL。
还是刚才的员工部门例子。现在你想列出所有员工，包括那些还没分配部门的：
SELECT e.emp_name, d.dept_name FROM employee e LEFT JOIN department d ON e.dept_id = d.id;结果为“未分配部门的员工”保留一行，dept_name显示NULL。这在做数据完整性检查时非常有用。
还有一种全外连接（FULL OUTER JOIN），语义是两边都保留，任何一边不匹配都补NULL。MySQL原生不支持FULL OUTER JOIN，但可以通过UNION把左连接和右连接的结果合并起来：
SELECT e.emp_name, d.dept_name FROM employee e LEFT JOIN department d ON e.dept_id = d.id UNION SELECT e.emp_name, d.dept_name FROM employee e RIGHT JOIN department d ON e.dept_id = d.id;UNION会自动去重，左右连接重复匹配的行只保留一行。
3.4 连接条件放ON和放WHERE，结果天差地别
这是外连接最大的坑。内连接中，ON和WHERE效果一样。但在LEFT JOIN中，把过滤条件写在WHERE里，会改变连接的语义。
比如你想查“所有员工，以及他们所在部门名称，但只看技术部的员工”。你可能会这么写：
SELECT e.emp_name, d.dept_name FROM employee e LEFT JOIN department d ON e.dept_id = d.id WHERE d.dept_name = '技术部';结果出来你会发现，没分配部门的员工不见了，已经匹配但不是技术部的员工也不见了，LEFT JOIN好像变成了INNER JOIN。原因在于：LEFT JOIN先把左表和右表按ON条件连接，得到“所有员工+匹配部门”的临时表，然后在WHERE阶段过滤，而WHERE把左表中部门为空的行过滤掉了，左连接的保护作用失效。
正确做法是把“技术部”这个过滤条件放到ON里：
SELECT e.emp_name, d.dept_name FROM employee e LEFT JOIN department d ON e.dept_id = d.id AND d.dept_name = '技术部';这才是真正的“保留所有员工，技术部的显示部门名，非技术部的部门名为NULL”。一个条件的放置位置不同，结果语义完全不同，这在写报表SQL时必须十二分注意。
4. 聚合与连接结合的真实场景实操
4.1 一个能练手的三表场景
纸上谈兵没意思。我设计一个电商场景，三张表，互相之间通过外键关联。
用户表users：存储用户基本信息，常见字段包括id、user_name、reg_date。
订单表orders：每笔订单一行，字段包括id、user_id、total_amount、order_date。user_id指向users.id，表示这笔订单属于哪个用户。
订单明细表order_items：每个订单可能包含多件商品，一行是一个商品条目。字段包括id、order_id、product_name、price、quantity。order_id指向orders.id。
现在要做几个聚合统计，难度从低到高。
4.2 场景一：统计每个用户的订单总金额和订单数
需求说明：把每个用户的订单数量、消费总金额算出来。这需要先按用户维度聚合，再关联用户表取出用户名。
SELECT u.user_name, COUNT(o.id) AS order_count, COALESCE(SUM(o.total_amount), 0) AS total_spent FROM users u LEFT JOIN orders o ON o.user_id = u.id GROUP BY u.id, u.user_name;拆解一下这段SQL的思路：
- FROM users u LEFT JOIN orders o：以用户表为主表，确保没有任何订单的用户也出现，订单数显示0。
- GROUP BY u.id, u.user_name：按用户分组。这里把u.id也放进分组，是为了符合ONLY_FULL_GROUP_BY的约束，同时保证用户重名时也不会把不同用户合并成一组。
- COUNT(o.id)：统计该用户关联的订单数量。注意，如果用户没有订单，LEFT JOIN会拼接出一行“所有字段都是NULL”的虚拟记录，o.id是NULL，COUNT(o.id)会返回0，刚好满足需求。
- COALESCE(SUM(o.total_amount), 0)：把NULL金额转成0，避免后续计算出现NULL污染。
为什么不直接COUNT()?因为COUNT()在LEFT JOIN的场景下，没订单的用户也会统计到一行（那行全是NULL），数量会变成1而不是0，所以必须写成COUNT(o.id)。
4.3 场景二：统计每个订单是否包含指定商品及数量
需求说明：查出每个订单的客户姓名、订单总金额，以及在订单明细里某件商品（比如“无线键盘”）的购买数量。如果没买过，数量为0。
SELECT u.user_name, o.id AS order_id, o.total_amount, COALESCE(SUM(oi.quantity), 0) AS keyboard_quantity FROM orders o JOIN users u ON u.id = o.user_id LEFT JOIN order_items oi ON oi.order_id = o.id AND oi.product_name = '无线键盘' GROUP BY u.user_name, o.id, o.total_amount;这个SQL的细节技巧在于：把product_name = '无线键盘'的条件放进LEFT JOIN的ON里，而不是WHERE里，否则没有该商品的订单会被整体过滤掉，统计结果就会缺失。
GROUP BY里包含了o.total_amount和u.user_name。这些列虽然在功能上由o.id唯一决定，但MySQL的ONLY_FULL_GROUP_BY模式要求SELECT中出现的非聚合列必须出现在GROUP BY中，写全它们才能避免报错。
4.4 场景三：查询出商品销售排行
需求说明：按商品维度统计销量和销售额，并降序排列。
SELECT oi.product_name, SUM(oi.quantity) AS total_quantity, SUM(oi.quantity * oi.price) AS total_sales FROM order_items oi GROUP BY oi.product_name ORDER BY total_sales DESC;这里没有涉及连接，但是展示了聚合查询中另一个容易被忽略的细节：聚合函数里可以写表达式。SUM(quantity * price)是对每行先计算金额再求和，语义上是“所有订单明细行的金额总和”，完全合法。ORDER BY里用了聚合函数得到的别名total_sales，这个顺序是正确的——因为ORDER BY执行在SELECT之后，此时别名已经生成。
如果想更进一步，关联orders表筛选出本季度的数据，可以加上JOIN和WHERE：
SELECT oi.product_name, SUM(oi.quantity) AS total_quantity, SUM(oi.quantity * oi.price) AS total_sales FROM order_items oi JOIN orders o ON o.id = oi.order_id WHERE o.order_date >= '2024-10-01' AND o.order_date < '2025-01-01' GROUP BY oi.product_name ORDER BY total_sales DESC LIMIT 10;注意一个细节：这里的JOIN条件是o.id = oi.order_id，关联的是订单主键，一对多关系下不会导致数据重复。如果关联条件写反了，可能引发下一个小节提到的问题。
5. 常见问题与排查技巧实录
5.1 ONLY_FULL_GROUP_BY报错，SELECT字段不合法
MySQL 5.7及以上版本默认开启ONLY_FULL_GROUP_BY模式，报错信息类似：
Expression #4 of SELECT list is not in GROUP BY clause and contains nonaggregated column ...这行报错绝对是聚合查询新手遇到最多的坑。意思是：SELECT后面的第4个字段，既没有出现在GROUP BY里，也没有被聚合函数包裹。
解决办法有两个方向：
第一种，把这个字段加进GROUP BY。如果你确认该字段的值在分组内是唯一的（比如按订单ID分组，订单ID对应的用户ID就是唯一的），加上之后结果不会出错。
第二种，如果不想加，可以用ANY_VALUE()函数包住这个字段，告诉MySQL“这列随便挑一个值就行”，适用于你明确知道组内该列值相同的场景。但要用这个函数得先确认逻辑正确性，否则拿到随机值，报表数据就会悄悄出错。
5.2 关联查询后聚合结果翻倍
这个问题隐蔽性极强。症状是：查询用户订单的时候，发现SUM(total_amount)的结果是实际值的两倍甚至好几倍。原因通常出在JOIN导致数据行重复上。
比如订单表orders和订单明细表order_items连接之后，如果一个订单包含3个商品，这个订单在结果里会变成3行。如果此时对orders.total_amount求和，金额就被重复计算了3次。
这种问题的排查思路：先不做聚合，直接SELECT两个表的主键和关键字段查看明细行数，对比JOIN前后的行数变化，确认是否有重复。确认之后，可以选择改用子查询或者提前在子查询里完成聚合，再和主表连接：
SELECT u.user_name, o.order_id, o.total_amount, t.item_count FROM orders o JOIN users u ON u.id = o.user_id LEFT JOIN ( SELECT order_id, COUNT(*) AS item_count, SUM(quantity) AS item_quantity FROM order_items GROUP BY order_id ) t ON t.order_id = o.id;这样订单金额只来自orders表本身，不会被明细表放大。
5.3 关联查询就是慢，怎么定位瓶颈
多表查询的性能问题通常有三个原因：缺索引、回表太重、查询条件没走索引。
优先检查JOIN关联字段是否有索引。employee的dept_id、orders的user_id、order_items的order_id，这些字段都应该有索引。没有索引的情况下，MySQL会对被驱动表做全表扫描，一个循环套一个循环，慢是必然的。
排查手段是EXPLAIN：
EXPLAIN SELECT ...重点看type列，从好到坏依次是const、eq_ref、ref、range、index、ALL。出现ALL意味着全表扫描，需要优化。再看rows估算值，判断扫描行数是否合理。还可以看Extra列，如果出现Using temporary或Using filesort，说明产生了临时表或文件排序，在数据量大时也会有明显性能损失。
5.4 外连接查询结果凭空多出很多行
连接查询中，如果连接条件没有落在唯一索引上，结果可能“一对多”。LEFT JOIN时，左表的一行如果对应右表多行，结果也会多行。排查时回到明细数据，去掉聚合，输出关联两表的主键，看哪张表的行在重复，就能快速定位。
另外，要留意多表连接时的连接顺序。虽然MySQL优化器会尝试调整连接顺序以找到最优执行计划，但LEFT JOIN的顺序在语义上是有方向的，不能随意交换左右表的位置，否则结果就不对了。
写在最后的实践经验
我平时写SQL有个习惯：任何聚合查询或连接查询，先在脑子里过一遍执行计划，FROM先读哪张表、WHERE过滤了哪些行、GROUP BY分了几组、JOIN是否会导致行数膨胀。遇到结果异常，从来不用“数据库是不是出bug了”来安慰自己，99.9%的情况下都是SQL逻辑问题。
对新手我的建议是：拿一套真实业务数据（比如自己建个订单表塞几千条测试数据），把上面提到的所有SQL都亲手跑一遍，对比加不加LEFT JOIN的结果差异、HAVING和WHERE的差异、ON放条件和WHERE放条件的差异。跑完这些，你对MySQL查询的理解会上升一个台阶。这些坑我当年一个一个踩过去，花了不少时间，希望你不用再踩一遍。
