做MySQL查询写过一阵子之后，你会发现一个很有意思的现象：很多复杂到让人头秃的SQL，其实翻来覆去就那么三板斧——聚合、分组、联合。但就是这三板斧，用好了能处理绝大多数业务查询需求，用不好就容易写出“结果对不上”“莫名卡死”“数据翻倍”这类问题。
这篇内容不打算从安装配置开始讲起，直接聚焦查询本身，把聚合、分组、联合这三块核心能力串成一个整体来看。你会看到它们各自的适用场景、语法细节、坑点，以及怎么把三者组合起来去构建一套“立体”的查询逻辑。不管是刚接触MySQL的新手，还是写过一段时间但一直靠复制粘贴写SQL的开发者，这篇都能帮你把底层的查询思路理顺。
1. 为什么说这是一个“立体拼图”
先聊一个比较容易被忽略的点：聚合、分组、联合，单独看都不难，难的是理解它们之间的配合关系。很多人学SQL是线性学的，今天学了个SUM，明天学了GROUP BY，后天学了LEFT JOIN，但真到写的时候却不知道怎么串起来，因为脑子里没有一张“地图”。
聚合解决的是“把一个集合压成一个值”的需求。比如求和、计数、取最大值，本质都是把多行数据折叠成一行结果。但聚合有一个天然的问题：一旦你只聚合不分组，整张表就变成了一行，原来的每行细节全没了。这就是分组的价值。
分组解决的是“按某个维度切分数据”的需求。GROUP BY把数据切成一堆小桶，每个桶内部再做聚合，这样既能保留维度信息，又能得到每个维度下的统计结果。换句话说，分组是聚合的“坐标”，聚合是分组的“度量”。
联合解决的是“把多张表或多个结果拼在一起”的需求。JOIN是横向拼接，把两张表的列并在一起；UNION是纵向拼接，把两个查询的行并在一起。联合的价值在于，它把零散在各处的数据重新组织成一个完整的视图，让聚合和分组有了更大范围的操作对象。
这三者在我眼里就是三个维度。聚合是“纵向的压缩”，分组是“横向的切分”，联合是“跨源的融合”。当你需要同时处理“多表数据”和“统计汇总”时，这三块就必须拼在一起用了，这也就是所谓立体的含义。
一个很常见的例子：运营要一份报表，内容是按月份统计每个品类的销售额、订单量和退款率。这个需求里，“按月份和品类”是分组，“销售额、订单量、退款率”是聚合，“订单表、订单明细表、退款表”之间的关联是联合。三者缺一不可，而且顺序错了结果就会错。
所以这篇内容的叙述逻辑就是：先分别拆解聚合、分组、联合各自的原理和用法，然后用实战案例把它们拼起来，最后整理高频问题和排查技巧。这样读下来，你会发现自己写SQL的时候不再是靠猜，而是有清晰的推导逻辑。
2. 聚合函数：数字提炼的底层逻辑
2.1 常用聚合函数的行为差异
MySQL里的聚合函数，日常用到的基本上是COUNT、SUM、AVG、MAX、MIN这五个。但很多人对它们的理解只停留在“会用”，并不清楚边界行为，而边界行为恰恰是出Bug的重灾区。
先说COUNT。COUNT(*)和COUNT(字段名)有本质区别。COUNT(*)统计的是行数，不管这一行有没有NULL；COUNT(字段名)统计的是该字段非NULL的个数，NULL直接被跳过了。这个区别在处理左连接结果时非常容易踩坑。比如用LEFT JOIN关联订单和退款记录，如果订单没有退款，退款表那侧就是NULL行，此时COUNT(退款表.id)统计的是有退款的订单数，而COUNT(*)统计的是所有订单数。
COUNT(DISTINCT 字段)也很常用，但性能需要关注，它在数据量大时会产生临时表排序或哈希操作，慢是正常的，得想别的优化办法，比如用近似去重或者提前在子查询里做去重。
再说SUM。SUM(字段)同样忽略NULL，但如果整个集合全是NULL或者空集，SUM返回的不是0，而是NULL。这在报表程序里经常引发空指针或者说“明明没数据却显示空白”的问题。稳妥做法是配合IFNULL或者COALESCE包一层。
AVG也容易让人误解。它只对非NULL值求平均，分母不是总行数，而是非NULL行数。假设某商品评价表有100条记录，其中80条有评分，AVG(评分)的分母是80而不是100。如果你想要“没有评分按0分算”的平均分，就得自己写：SUM(评分)/COUNT(*)。
MAX和MIN相对简单，不过有个细节：对字符串字段取MAX用的是字典序，不是数值大小。比如对订单号取MAX，如果想找“数值最大的订单号”，字符串排序可能会给出和预期完全不同的结果。
2.2 聚合结果为空时的处理策略
聚合查询返回空集这个问题，我见过太多次了。最典型的场景：按日期筛选订单，某天恰好没有订单，SELECT COUNT(*) FROM orders WHERE date = '2025-01-01'返回0行结果，而不是一行0。如果你是在程序里拿这个结果取值，直接取不到，程序可能就报错了。
解决思路有两个方向。
第一个方向是在SQL层统一返回一行结果，用聚合函数套条件表达式的方式，常见写法是COUNT(IF(条件, 1, NULL))，或者更通用的SUM(CASE WHEN 条件 THEN 1 ELSE 0 END)。这样即使没有数据，每一行聚合值也会是0。
第二个方向是在外层包一层查询，把空结果和真实结果统一起来。比如先查一个“基准集合”，再用LEFT JOIN去关联统计数据，这样基准集合保证了行数，统计值缺失的地方自然显示为NULL，再配合IFNULL补0。
这两种方案没有绝对优劣，取决于你对行数的要求。如果只关心某个汇总值，用前者；如果后续还要继续JOIN，用后者更容易保持行数语义。
2.3 聚合与性能之间的平衡
聚合操作看着简单，但数据量大时很考验MySQL的执行能力和SQL写法。COUNT(DISTINCT)在百万级数据上就可能跑到秒级，SUM带复杂条件表达式也会拖慢速度。
我个人的经验是按优先级做三件事：第一，尽量在WHERE阶段先缩小数据集，让聚合操作作用在小集合上；第二，能用COUNT(*)就别用COUNT(DISTINCT)，如果必须去重，尝试在子查询中先DISTINCT再COUNT，有时候优化器处理起来更高效；第三，聚合时避免对索引字段做函数操作，比如DATE(create_time)这种写法会让索引失效，能改成create_time >= '2025-01-01' AND create_time < '2025-01-02'才是更好的写法。
这些点看着零碎，但组合在一起决定了同样的SQL在不同数据量下的表现差异。
3. 分组：维度切分与分组后的精细控制
3.1 GROUP BY的基础行为与执行顺序
GROUP BY的本质是给数据“打标签归类”。整张表的数据根据分组字段的值被划分成若干小组，然后每个小组被压缩成一行输出，而这一行的非分组字段值必须通过聚合函数来汇总。
理解执行顺序对写SQL很重要。MySQL的SQL执行顺序大致是FROM->WHERE->GROUP BY->HAVING->SELECT->ORDER BY->LIMIT。这个顺序解释了为什么WHERE里不能用聚合结果，而HAVING里可以；也解释了为什么SELECT里取的别名在WHERE里不能用，但在ORDER BY里可以用。
很多初学者会在WHERE里写SUM(amount) > 100这种条件，然后报错或得到错误结果。因为WHERE是在分组之前执行的，它只能过滤原始行，不能过滤分组后的结果。正确做法是把过滤条件放在HAVING里。
一个典型的场景：找出消费总额超过1000元的用户。你不可能在WHERE阶段知道用户的累计消费额，必须先把所有订单按用户分组并求和，然后再筛选。这个“筛选分组结果”的动作就是HAVING。
3.2 多字段分组与表达式分组
GROUP BY的字段可以是一个，也可以是多个。多个字段分组的效果是“按组合维度切分”。比如GROUP BY year, month，结果就是每一对“年+月”组合一行数据，相当于做了一个二维的透视表。
除了字段名，GROUP BY还支持表达式。比如按月份分组不一定要有月份字段，可以用DATE_FORMAT(create_time, '%Y-%m')直接作为分组键。这个能力在统计报表链路里特别常用。
还有一个容易被忽略的点：GROUP BY的分组键也可以在SELECT里不展示。比如你想统计每个客户的订单总量，但只需要输出客户ID和总金额，不输出客户姓名，这完全没问题。MySQL不像某些数据库那样强制要求SELECT的列与GROUP BY完全对齐，但如果你只开ONLY_FULL_GROUP_BY模式（MySQL 5.7及以上默认开启），SELECT中出现的非聚合列必须出现在GROUP BY中，否则直接报错。
关于ONLY_FULL_GROUP_BY，我多说一句。很多人遇到这个报错第一反应是关掉它，我不建议这么做。这个模式的初衷是防止你写出“语义不确定”的SQL。比如按用户分组，却直接从组内随机取一个订单金额，这在逻辑上本来就是模糊的。真遇到“分组后取组内某条记录”的需求，正确姿势是用子查询、窗口函数或者GROUP_CONCAT来处理，而不是靠关闭模式来绕过。
3.3 分组之后如何取每组的前N条
分组后取每组前N条，这个需求在任何业务系统里都高频出现。比如每个品类销量最高的商品，每个用户最近一笔订单。
在MySQL 8.0之前的版本，这个需求非常痛苦，网上的解决方案千奇百怪，有写GROUP_CONCAT再拆的，有用用户变量的，都不够优雅。MySQL 8.0之后有了窗口函数，这个问题就简单了。
思路是使用ROW_NUMBER()按组内排序编号，然后外层查询只保留编号小于等于N的行。比如：
SELECT * FROM ( SELECT p.*, ROW_NUMBER() OVER (PARTITION BY category_id ORDER BY sales DESC) AS rn FROM products p ) t WHERE t.rn <= 3;这里PARTITION BY category_id就是“按品类分组”，ORDER BY sales DESC是“组内按销量倒序”，ROW_NUMBER()负责编号，外层WHERE rn <= 3就是取前三。
窗口函数的价值在于它不需要把表压缩成一行，可以在保留原始行的同时附加分组编号，这在很多复杂分析场景里是绝对的利器。
3.4 分组的衍生能力：ROLLUP与GROUP_CONCAT
WITH ROLLUP是分组统计的一个副产品能力。它在分组结果最后追加一行总计，相当于自动帮你做了一个“全部维度”的汇总。比如GROUP BY category统计销售额，WITH ROLLUP会在末尾多出一行显示所有品类的总销售额，省去你再写一次UNION ALL的麻烦。
GROUP_CONCAT则解决的是“分组后把组内字段拼接成字符串”的问题。比如按用户分组，把该用户的所有订单号用逗号拼起来。需要注意两点：第一，默认最大长度是1024字节，超出会被截断，需要提前SET SESSION group_concat_max_len = 102400调整；第二，GROUP_CONCAT内可以用ORDER BY子句控制拼接顺序，比如GROUP_CONCAT(order_id ORDER BY create_time DESC)。
这两个功能不常用，但一旦需要，效果非常惊艳，能省掉大量应用层代码。
4. 联合查询：跨表与跨结果集的拼接逻辑
4.1 JOIN与UNION的本质区别
很多人在学“联合查询”时，会把JOIN和UNION混在一起，这其实是一个巨大的误区。它们在方向上完全不同。
JOIN是横向拼接——把两张表的列合并到一起。订单表有一列用户ID，用户表有用户姓名，JOIN之后，一行结果里可以同时有订单信息和用户姓名。结果集的列数增加了，行数一般也会变（取决于关联关系）。
UNION是纵向拼接——把两个查询的行合并到一起。一个查询返回上半年的订单，另一个查询返回下半年的订单，UNION之后就是全年的订单。结果集的行数增加了，但列数必须一致。
用生活例子打比方：JOIN像是把两个人的信息写在一张卡片上，UNION像是把两组卡片摞在一起。
理解了方向区别，就能避免很多低级错误。比如“查所有订单及其用户信息”用JOIN；而“查所有买了A商品或B商品的用户”用UNION（去重）或UNION ALL（不去重）。两者目的完全不同。
4.2 JOIN的几种类型与应用场景
JOIN的常用类型就四个：INNER JOIN、LEFT JOIN、RIGHT JOIN、CROSS JOIN。
INNER JOIN只保留两边都匹配的行。适合“只关心有完整关联关系的数据”的场景，比如只要那些有支付记录的订单。
LEFT JOIN保留左表全部行，右表没有匹配的补NULL。这是业务系统里最常用的，因为很多场景需要“以左表为主体，额外补充右表信息”。比如列出所有商品，附带最近一次促销活动信息，没有促销活动的商品也照样显示。
RIGHT JOIN和LEFT JOIN是对称的，但现实编码中很少用RIGHT JOIN，因为把两张表调换位置用LEFT JOIN更符合阅读直觉。
CROSS JOIN是笛卡尔积，两边所有行两两组合。这个一般只用于构造测试数据或者特定算法场景，业务里出现基本就是写错了。
另外还有个SELF JOIN（自连接），一张表和自己关联。典型场景是“查员工及其上级姓名”——一张员工表里同时存有员工信息和上级ID，需要用两次这张表来分别取员工和上级。
4.3 JOIN的ON与WHERE：时机决定语义
JOIN里最容易出错的地方，不是不会写语法，而是搞不清楚ON条件和WHERE条件的语义差异。
ON是在JOIN过程中用来决定“哪些行能匹配上”的；WHERE是在JOIN完成后用来过滤结果的。对于INNER JOIN，两者写在哪儿结果一样（优化器会帮你等价转换）；但对于LEFT JOIN，区别就大了。
举个例子：左表orders，右表refunds。你想列出所有订单，并附上退款金额；但只想显示状态为“成功”的退款。
如果条件写在ON里：
SELECT o.order_id, r.amount FROM orders o LEFT JOIN refunds r ON o.order_id = r.order_id AND r.status = 'success';结果是所有订单都保留，退款金额只有退款状态为success的才会有值，其余订单显示NULL。
如果条件写在WHERE里：
SELECT o.order_id, r.amount FROM orders o LEFT JOIN refunds r ON o.order_id = r.order_id WHERE r.status = 'success';结果完全不同了——因为WHERE先执行，那些没有成功退款的订单会被过滤掉，订单行数减少，左表主体语义被破坏。
这个区分在写报表SQL时极其重要。我见过太多“同样的SQL写法不同，结果行数差一大截”的线上事故，追根溯源全是ON和WHERE的时机问题。
4.4 UNION与UNION ALL的选择
UNION和UNION ALL的差异在于去重。UNION会先合并结果再对重复行做去重，因此需要额外的排序或哈希操作；UNION ALL直接拼接所有行，不去重，速度更快。
从业务角度，只有在你明确知道需要“合并并去重”时才用UNION。如果你能保证两个查询的结果本身就不重复（比如一个是上半年的数据，一个是下半年的数据），直接用UNION ALL，没必要付出去重的代价。
另外要注意，UNION对每个SELECT的列数和列类型有要求：列数必须一致，类型要能兼容。MySQL虽然不做严格类型校验，但隐式转换可能导致意外结果。
还有一个小技巧：UNION只支持ORDER BY和LIMIT放在最后一个SELECT之后，用来对整体合并结果排序或截取。如果你试图给每个子查询单独排序再合并，排序是无效的，MySQL会忽略子查询里的ORDER BY（除非配合LIMIT）。
5. 三块拼图组合实战：从业务需求到完整SQL
5.1 一个典型的综合统计需求
理论部分聊得差不多了，接下来用一个具体案例把聚合、分组、联合串起来走一遍。
假设现在有三张表：orders（订单表，记录订单ID、用户ID、下单时间、订单总金额）、order_items（订单明细表，记录订单内每个商品，含商品ID、数量、单价）、products（商品表，含商品ID、品类ID、商品名）。
业务需求：统计2024年每个季度的销售额，并且按品类维度拆开，同时要求只显示销售额超过10万元的品类。另外还要附带该品类的订单数量。
这是一个典型的“三表联合+分组聚合+结果过滤”的综合需求。先从最简单的方向拆解。
5.2 第一步：先求销售明细
想知道每个品类的销售额，必须先明确“销售额”怎么算。这里取一个常见口径：销售额 = 订单明细里的数量 × 单价。订单明细表里有单价字段，可以直接用。但要注意退款订单是否剔除，这里假设不需要。
于是核心数据源是order_items，它本身没有品类和下单时间的信息，需要通过orders和products来补充。
SELECT p.category_id, QUARTER(o.order_date) AS q, oi.quantity * oi.price AS sales_amount, o.order_id FROM order_items oi JOIN orders o ON oi.order_id = o.order_id JOIN products p ON oi.product_id = p.product_id WHERE o.order_date >= '2024-01-01' AND o.order_date < '2025-01-01';这一步是“联合”，目的就是把散落在多张表里的信息拼到同一行。这里用INNER JOIN，因为订单明细必然有对应订单和商品，不存在补NULL的需求。
5.3 第二步：按品类和季度聚合
有了明细数据，下一步就是分组聚合。目标是每个品类在每个季度的销售额和订单量。
SELECT p.category_id, QUARTER(o.order_date) AS q, SUM(oi.quantity * oi.price) AS total_sales, COUNT(DISTINCT o.order_id) AS order_cnt FROM order_items oi JOIN orders o ON oi.order_id = o.order_id JOIN products p ON oi.product_id = p.product_id WHERE o.order_date >= '2024-01-01' AND o.order_date < '2025-01-01' GROUP BY p.category_id, q;这里GROUP BY用了两个字段，因为维度是“品类 + 季度”。COUNT(DISTINCT o.order_id)用来统计订单数量，为什么不是COUNT(*)？因为一个订单里可能包含同一个品类的多个商品明细，COUNT(*)会把同一订单的多条明细都算进去，导致订单数虚高。用DISTINCT才是真正按订单去重计数。
注意GROUP BY q这里用的是SELECT中的别名。MySQL允许在GROUP BY中使用别名，但建议别依赖这个特性，可移植性不好，最好直接写QUARTER(o.order_date)。
5.4 第三步：过滤分组结果并排序
聚合完了，现在要过滤“销售额超过10万元”的品类-季度组合。这个条件针对的是分组后的结果，必须用HAVING。
SELECT p.category_id, QUARTER(o.order_date) AS q, SUM(oi.quantity * oi.price) AS total_sales, COUNT(DISTINCT o.order_id) AS order_cnt FROM order_items oi JOIN orders o ON oi.order_id = o.order_id JOIN products p ON oi.product_id = p.product_id WHERE o.order_date >= '2024-01-01' AND o.order_date < '2025-01-01' GROUP BY p.category_id, QUARTER(o.order_date) HAVING total_sales > 100000 ORDER BY q, total_sales DESC;这里HAVING里可以直接用total_sales这个别名，因为HAVING在SELECT之后执行，别名已经生效。同样ORDER BY也可以用别名。
最后ORDER BY q, total_sales DESC让结果先按季度排，再按销售额倒序排，报表看起来更直观。
5.5 第四步：如果还要把各季度总计也放进结果
如果运营希望每个季度结尾看到“本季度所有品类的总销售额”，可以用WITH ROLLUP。在GROUP BY末尾加上WITH ROLLUP后，MySQL会在每个分组层级追加一行小计，最后还会有一行总计。
但ROLLUP的结果里，被汇总的维度字段显示为NULL，需要通过IFNULL或CASE把NULL替换成“总计”这类标签。这里有一个坑：如果原始数据里品类ID本来就可能是NULL，会和ROLLUP的汇总行混淆，所以使用ROLLUP前要想清楚字段语义。
SELECT IFNULL(p.category_id, 'ALL') AS category_id, IFNULL(QUARTER(o.order_date), '季度汇总') AS q, SUM(oi.quantity * oi.price) AS total_sales FROM order_items oi JOIN orders o ON oi.order_id = o.order_id JOIN products p ON oi.product_id = p.product_id WHERE o.order_date >= '2024-01-01' AND o.order_date < '2025-01-01' GROUP BY p.category_id, QUARTER(o.order_date) WITH ROLLUP;这个SQL在报表导出场景非常实用，一行代码免去了应用层再算小计的麻烦。
5.6 组合使用的执行逻辑推演
写组合SQL时，心里要能推演执行流程，这样出了问题才能快速定位。
拿上面的SQL为例，MySQL大致执行顺序是：
- 先从
order_items开始，JOIN orders和JOIN products，把三张表的数据关联成一张“宽表”。此时表里每一行都有品类、季度、数量、单价、订单ID信息。 WHERE过滤掉2024年之外的数据，缩小处理范围。GROUP BY把宽表按“品类 + 季度”分桶。- 在每个桶里执行
SUM和COUNT(DISTINCT)。 HAVING过滤掉总销售额不超过10万的组。SELECT输出需要的列。ORDER BY排序。- 如果带
ROLLUP，MySQL会在分组聚合后追加汇总行，然后再排序输出。
这个推演过程非常重要。你能清晰地知道每一步数据的形状——行数怎么变、列数怎么变、NULL从哪来、数据会不会翻倍——就说明你真正掌握了组合查询。
6. 高频问题排查与避坑实录
6.1 GROUP BY相关报错与处理
报错：Expression #N of SELECT list is not in GROUP BY clause and contains nonaggregated column...
这个报错就是ONLY_FULL_GROUP_BY模式在起作用。处理方法不是关模式，而是审查SQL语义。
比如：
SELECT user_id, order_amount FROM orders GROUP BY user_id;这个语句的问题在于：每个用户组内可能有很多订单金额，order_amount到底取哪一个？语义不明。
正确做法有三种：
- 如果你要的是总和，写成
SELECT user_id, SUM(order_amount) FROM orders GROUP BY user_id; - 如果你要的是组内某个特定条件的值，用子查询或窗口函数定位后再取
- 如果你就是想要组内第一条，MySQL 8.0用
ROW_NUMBER()最稳妥
6.2 COUNT统计不准的数据翻倍问题
现象：明明订单只有100个，JOIN明细表之后COUNT(*)变成了300。
原因：一个订单包含3个商品明细，JOIN order_items后每个订单变成了3行，COUNT(*)自然统计为3。
排查思路：这种问题几乎都出在“一对多JOIN”之后直接做聚合统计时，没有意识到行数已经被放大。解决办法是先看中间结果的行数，再决定统计口径。如果统计的是订单数，必须用COUNT(DISTINCT orders.id)；如果统计的是明细行数，才可以用COUNT(*)。
我的习惯是，写任何带JOIN的聚合SQL之前，先分别跑一下三张表的行数和关键ID的唯一数，做到心里有数，再写聚合。
6.3 LEFT JOIN之后聚合结果意外减少
现象：LEFT JOIN明明左表是全量数据，但聚合之后行数变少了。
原因：大概率是WHERE里写了右表字段的条件。如前文所说，WHERE会把无法匹配的行过滤掉，LEFT JOIN语义被破坏。正确的做法是把右表条件挪到ON里，或者先聚合右表再JOIN。
还有一种情况是聚合后再JOIN，JOIN条件不满足导致部分行被丢弃。比如先按订单汇总退款总额，再LEFT JOIN订单表，由于某些订单没有退款记录，聚合结果里根本没有这行，导致JOIN不上。这时需要先保证主表行数完整，或者用IFNULL(退款表统计值, 0)提前安排默认值。
6.4 UNION排序失效的坑
现象：UNION的每个子查询里都写了ORDER BY，但最终结果并没有按预期排序。
原因：MySQL对UNION子查询里的ORDER BY有严格限制：如果不带LIMIT，子查询里的ORDER BY会被优化器直接忽略，因为子查询的排序结果在合并时没有意义。只有最后一个SELECT之后的ORDER BY才会作用于整体合并结果。
正确做法：
SELECT user_id, amount FROM orders_2024_a UNION ALL SELECT user_id, amount FROM orders_2024_b ORDER BY amount DESC LIMIT 10;如果需要先对每个子查询截取再合并，子查询里要写LIMIT才能让ORDER BY生效。
6.5 HAVING与WHERE的误用
现象：过滤条件写在WHERE里，但发现结果和预期不符，某些组还被错误过滤掉。
原因：WHERE根本无法引用聚合结果。比如你要找“总消费额大于1000的用户”，如果写WHERE SUM(amount) > 1000直接报错；写WHERE amount > 1000则变成“只统计单笔超过1000的订单”，语义完全不同。
判断标准：条件针对原始行——用WHERE；条件针对分组后的聚合值——用HAVING。这条记忆法简单且有效。
6.6 性能排查：为什么会越查越慢
复杂组合查询的性能问题，多半出在JOIN顺序和分组的数据量上。几个实际经验：
第一，先过滤再JOIN。能在一张表内部先WHERE缩小的，一定要先缩小，不要让优化器把大表和大表先JOIN再过滤。子查询里先聚合再JOIN，往往比直接JOIN再聚合快很多。
第二，JOIN字段要有索引。这是最基础但最容易被忽略的。两表JOIN的关联字段，如果是主键或唯一键自然没问题；如果不是，必须检查是否有索引。没有索引的JOIN，数据量稍大就会变成灾难。
第三，慎用SELECT *。JOIN之后再SELECT *会把所有表的无关列都查出来，增加网络传输和临时表空间消耗。只查你需要的列。
第四，分页和聚合配合时注意性能。大数据量下LIMIT 10000, 20这种深分页非常慢，性能问题的根源在于它先查了前面10020行再丢弃前10000行。如果可能，利用排序字段的主键范围来改写成WHERE id > 上次最大id LIMIT 20。
7. 我的几点实操体会
写了大量查询SQL之后，我最深的一个体会是：绝大多数查询问题不是语法问题，而是语义问题。能不能写出来是次要的，能不能明确“我要的结果是多少行、每行代表什么、NULL意味着什么”才是核心。而聚合、分组、联合这三个操作，恰恰最容易模糊语义：聚合会丢行、分组会切维度、联合会放大或拼接行。每一步操作前，先问自己“现在的结果集会变成什么样”，就能避开大部分坑。
另一个体会是，调试聚合JOIN类SQL时，最好的工具不是某个数据库客户端，而是“分步执行”。把SQL拆成几段，先跑子查询看中间结果，再层层套上去核对。经验再丰富的人也没法一眼看出3层嵌套的SQL哪里错，但分步执行每一步都能验证行数和数值，问题很快就能暴露。
第三个体会是，能控制在SQL里的尽量控制在SQL里，但不要勉强。有些复杂需求——比如多层窗口函数嵌套、递归查询——虽然SQL能写出来，但可读性和维护性都很差。这个时候在应用层拆两步，把中间结果缓存一下，反而更清晰更高效。技术选型永远是为了解决问题，不是为了炫技。
最后分享一个小技巧：写聚合查询时，习惯性地在各阶段加一列“行数标记”，比如在SELECT里加一个COUNT(*) OVER()来观察当前结果集的总行数。这在调试复杂嵌套查询时极其有用，能直观看到每一步的行数变化，比反复数结果集要高效得多。
MySQL查询的立体拼图，说到底就是这三个维度的自由组合。把每一块的原理吃透，把组合的逻辑推演清楚，遇到再复杂的业务需求，你也能快速拆解出对应的SQL结构。
