做后端开发这些年，MySQL复合查询是躲不开的坎。报表需求、多条件筛选、多表统计，几乎天天都在写。很多人一开始习惯把逻辑拆成好几条SQL，在应用层用for循环做关联和过滤，短期能跑，数据量一上来就卡得让人挠头。复合查询说白了，就是在一个SQL里同时组合多个条件、多个表、多个聚合层，让数据库把脏活累活干完，直接吐出最终结果。这篇文章我会把WHERE组合、JOIN过滤、子查询、聚合HAVING这些逻辑串起来讲，配合真实业务场景和踩坑记录，适合正在写业务SQL的后端、数据开发或者运维同学参考。
1. 为什么需要复合查询：别再用“查完再算”
1.1 单表查询的极限和“查完再算”的代价
单表查询本身不复杂，WHERE price < 100这种条件一眼能看懂。但真实业务往往不是单个条件，而是“状态、时间、金额范围、地域、用户等级”揉在一起。如果所有过滤都靠应用层循环，本质上是把一个查询变成了几十次、几百次小请求。比如先查出符合条件的用户ID，再逐个查订单，再在内存里做汇总，这种写法在数据量小的时候没什么感觉，但用户量到几千、订单量到几十万的时候，接口延迟会成倍上涨。
除了慢，这种“查完再算”还有一个隐蔽问题：多条SQL之间没有事务边界，容易读到中间状态。比如先查用户，再查订单，中间用户下了新订单，应用层统计出来的结果就可能对不上。与其在代码里拼来拼去，不如把条件、关联、分组全部交给MySQL一次算完。复合查询的天然优势就在这里：数据库在自己的事务和优化器体系内完成计算，返回一个独立结果集，无论从性能还是数据一致性上都更可控。
1.2 复合查询到底适合哪些业务场景
我总结下来，复合查询主要出现在四类场景里。
- 多条件筛选：电商商品列表里，价格区间、分类、库存状态、上架时间同时参与过滤。
- 多表关联统计：订单主表和明细表，需要一次查出订单数量、商品件数、总金额。
- 存在性判断：比如查“买过某类商品的用户”，用子查询或关联过滤。
- 分组后过滤：先按用户分组求出总额，再筛掉低于阈值的用户，这就是
HAVING典型的用法。
这些场景如果拆成多条SQL，代码会变得很绕，还容易引入N+1查询。复合查询不是银弹，但它能把“数据筛选、关联、聚合”这三件事集中在SQL层完成，让应用层只关心结果。理解这一点，再去看后面具体写法，思路会顺很多。
2. 认识复合查询的核心逻辑：WHERE、AND/OR、括号与优先级
2.1 先用最简单的条件组合热身
复合查询的起点就是WHERE里的多条件组合。下面的SQL看起来朴素，但已经包含了“状态、金额、时间”三种不同维度的过滤：
SELECT user_id, order_amount FROM orders WHERE status = 'paid' AND order_amount BETWEEN 100 AND 500 AND created_at >= '2024-01-01' AND created_at < '2024-02-01';这里四个AND彼此是“同时满足”的关系，每个条件都在缩小结果集。写这种SQL时有一个习惯特别重要：能写范围就别写函数。比如created_at字段要确保能用索引，就写成>=和<这种区间，不要写成DATE(created_at) = '2024-01-01'，否则索引会被函数挡住，查询可能变成全表扫描。
如果条件里有多个值，也可以把OR换成语义更清晰的IN。WHERE status = 'paid' OR status = 'refunded'写成WHERE status IN ('paid', 'refunded')，可读性会好很多。但注意，这只是写法优化，不等于IN一定比OR快，最终还要看执行计划和索引情况。
2.2 运算符优先级：AND 比 OR“亲”，括号别乱丢
很多人写复杂WHERE时最容易踩的坑，就是动用了OR却忘了括号。MySQL里AND的优先级高于OR，也就是说WHERE a OR b AND c会先算b AND c，然后再和a做OR。如果业务意图不是这样，结果就差远了。
举个例子，我想查“已支付或者待支付”的订单，同时订单金额要大于100，直觉写出来可能是：
WHERE status = 'paid' OR status = 'pending' AND amount > 100但这句SQL实际执行的是：status = 'paid' OR (status = 'pending' AND amount > 100)。也就是说，已支付订单不管金额多少都会进来，待支付订单才要求金额大于100。如果业务要求两种状态的订单都必须金额大于100，必须写成：
WHERE (status = 'paid' OR status = 'pending') AND amount > 100括号不是用来装饰的，它直接决定条件组合优先级。我的习惯是，只要条件里同时出现AND和OR，就无脑加括号，哪怕有些括号是多余的。这样既保护自己，也让接手代码的人不用猜逻辑。
2.3 别让 NULL 和空字符串把你绕进去
SQL里NULL不是“空值”那么简单，它代表“未知”。和未知做比较，结果还是未知，所以WHERE name = NULL永远查不到数据。正确写法是IS NULL或者<=>。这个道理多数人都知道，但放在复合查询里就很容易翻车。
比如判断一个用户是不是在黑名单里，常见写法是用NOT IN：
WHERE user_id NOT IN (SELECT user_id FROM blacklist)一旦子查询里的blacklist.user_id出现NULL，整个NOT IN的所有行都不会返回。原因很简单，如果子查询返回(1, NULL)，那么对每一行都要判断“当前user_id既不等于1，也不等于NULL”，和NULL比较的结果是未知，行就被过滤掉了。这时候应该改用NOT EXISTS：
WHERE NOT EXISTS (SELECT 1 FROM blacklist b WHERE b.user_id = users.id)NOT EXISTS的语义是“按关联条件逐行判断，存在则排除”，不会因为NULL导致整段逻辑失效。类似的坑还有空字符串和NULL混用，表中某列可能既有''也有NULL，条件里必须分别处理。写复合查询时，多留一个心眼：凡是可能有NULL的列，先想清楚IN、NOT IN、= NULL这些用法会不会出问题。
3. 把复合查询玩出花：JOIN、子查询与聚合组合
3.1 JOIN时，ON和WHERE过滤时机不一样
复合查询里出现JOIN之后，很多人搞不清过滤条件该放ON还是WHERE。如果是INNER JOIN，逻辑上放哪都行，优化器会自行优化。但换到LEFT JOIN，差别非常大。
比如查所有用户以及他们的已支付订单：
SELECT u.id, o.id FROM users u LEFT JOIN orders o ON o.user_id = u.id AND o.status = 'paid';这里o.status = 'paid'写在ON里，LEFT JOIN会保留左边所有用户，只是没有已支付订单的用户，右边字段会是NULL。但如果我把状态条件挪到WHERE：
SELECT u.id, o.id FROM users u LEFT JOIN orders o ON o.user_id = u.id WHERE o.status = 'paid';这句的执行逻辑就变了，它会先把users和orders做左连接，再用WHERE过滤出状态为paid的行，没有已支付订单的用户因为o.status是NULL，直接被过滤掉。这个查询的结果看起来和INNER JOIN一模一样，完全失去了LEFT JOIN的意义。
所以写LEFT JOIN时记住一句话：要不要保留左表的无匹配行，决定了过滤条件放ON还是WHERE。需要保留左表，关联条件和过滤条件都放ON；不需要保留，才可以把过滤放到WHERE。
3.2 子查询：IN、EXISTS和JOIN怎么选
子查询是复合查询的重要零件。查“某个等级用户下的订单”，可以用IN：
SELECT id, total_amount, created_at FROM orders WHERE user_id IN (SELECT id FROM users WHERE level = 3);这段SQL逻辑清楚，MySQL优化器在多数情况下也会自动做半连接优化。不过要注意，子查询里的结果集如果很大，IN的内存消耗会比较高，这时候换成EXISTS写法可能更稳：
SELECT o.id, o.total_amount, o.created_at FROM orders o WHERE EXISTS (SELECT 1 FROM users u WHERE u.id = o.user_id AND u.level = 3);EXISTS是相关子查询，对每个订单去判断用户是否存在。MySQL优化器也经常把IN改写成EXISTS或反过来，所以性能差异不是绝对的，最靠谱的办法是看执行计划。但在可读性上，IN更适合“先圈一个集合再查主表”的场景，EXISTS更适合“存在性判断”的场景。
如果子查询只是用来做关联并取字段，那不如直接JOIN。比如要同时返回用户昵称，就：
SELECT o.id, u.nickname, o.total_amount FROM orders o JOIN users u ON u.id = o.user_id WHERE u.level = 3;JOIN和子查询并不是谁绝对更好，而是语义不同。能用JOIN表达关联取数，就直接用；能用于查询表达集合归属，就用子查询；做存在性判断时，多考虑EXISTS。MySQL 8.0之后还可以用WITH公共表表达式把子查询抽出来，可读性会更强：
WITH paid_users AS ( SELECT id FROM users WHERE level = 3 ) SELECT o.id, u.nickname, o.total_amount FROM orders o JOIN paid_users pu ON pu.id = o.user_id JOIN users u ON u.id = o.user_id;3.3 聚合函数与HAVING：过滤放在聚合前还是聚合后
WHERE和HAVING都能做过滤，但作用时机完全不同。WHERE在分组聚合之前过滤原始行，HAVING在分组聚合之后过滤结果组。这个区别直接决定统计数字对不对。
比如统计每个用户的支付订单总金额，只保留总金额超过1000的用户：
SELECT user_id, SUM(total_amount) AS total_amount FROM orders WHERE status = 'paid' GROUP BY user_id HAVING SUM(total_amount) > 1000 ORDER BY total_amount DESC;这里status = 'paid'必须放WHERE，因为只想把已支付订单纳入求和，这是对原始行的过滤。HAVING SUM(total_amount) > 1000是对聚合结果的过滤，因为“总金额超过1000”这个条件依赖聚合值，不能放进WHERE。
注意一点，HAVING后面可以使用别名，比如HAVING total_amount > 1000在很多MySQL版本是允许的，但为了可移植性和可读性，我更推荐写完整的聚合表达式。还有，HAVING过滤必须在分组完成后，这个过程会消耗内存和CPU，能提前过滤的数据尽量在WHERE阶段过滤，千万别把所有行都聚合完再丢。
复合查询到这里已经出现了完整形态：WHERE做初步筛选，JOIN关联多表，GROUP BY分组，聚合函数计算，HAVING做二次过滤，ORDER BY排序。再配合LIMIT做分页，基本就是业务统计SQL的完整套路。
4. 复合查询远比想的更容易踩坑：性能与排查实录
4.1 索引失效：为什么加了索引还是慢
索引失效是复合查询最常见的性能杀手。我总结过几个高频翻车点。
第一个是对索引列使用函数。比如WHERE DATE(created_at) = '2024-01-01'，哪怕created_at上建了索引，MySQL也没法用，因为要先对每一行的列值执行函数再比较。正确写法是:WHERE created_at >= '2024-01-01' AND created_at < '2024-01-02'。
第二个是隐式类型转换。字段是VARCHAR，却拿数字去比较，比如WHERE mobile = 13800138000。MySQL可能把字符串列转成数字再比较，索引就失效了。正确做法是写成WHERE mobile = '13800138000'，让类型保持一致。
第三个是前导模糊匹配。LIKE '%key'这种写法无法走索引，因为索引是按最左前缀组织的。如果业务必须做后模糊匹配，要么考虑全文索引，要么在应用层想办法。
第四个是OR连接了非索引列。比如WHERE status = 'paid' OR category = 'book'，如果只有status有索引，category没有，优化器可能放弃索引扫描。遇到这种情况，可以把OR拆成两条SQL再用UNION ALL合并，让每条分支都能独立走索引，但前提是结果集语义一致。
判断索引到底有没有用，不要靠猜，直接看执行计划。EXPLAIN输出的type字段能从侧面反映扫描方式：
| type | 典型含义 |
|---|---|
| const/eq_ref | 主键或唯一索引精确匹配，性能最好 |
| ref | 普通索引等值匹配 |
| range | 索引范围扫描 |
| index | 全索引扫描，比ALL好但仍有代价 |
| ALL | 全表扫描，复合查询里要高度警惕 |
key字段会显示实际用到的索引，rows是预估扫描行数，Extra里出现Using temporary或Using filesort时，也要留意排序和分组是否消耗过大。
4.2 结果集放大：LEFT JOIN 引发的统计灾难
复合查询里另一个让我印象深刻的坑，是JOIN导致结果集翻倍。比如orders表一条订单对应order_items表多条商品明细。如果直接把两张表关联，再对orders.total_amount求和，同一个订单的金额会被明细行多次累加，统计结果会异常大。
看个错误例子：
SELECT o.id, COUNT(DISTINCT oi.id) AS item_count, SUM(o.total_amount) AS total_amount FROM orders o LEFT JOIN order_items oi ON oi.order_id = o.id GROUP BY o.id;这里SUM(o.total_amount)的金额会按order_items行数重复累加。为了避免“放大”问题，有几种处理方式。第一种是用COUNT(DISTINCT)去重，但它只能解决数量统计，解决不了金额重复累加。第二种是优先在子查询里先对明细表做聚合，再和主表关联，这也是我推荐的做法：
SELECT o.id, COALESCE(oi_stat.item_count, 0) AS item_count, o.total_amount FROM orders o LEFT JOIN ( SELECT order_id, COUNT(DISTINCT id) AS item_count FROM order_items GROUP BY order_id ) oi_stat ON oi_stat.order_id = o.id;先把明细聚合成单行，主表关联时就不会放大结果集。这个思路尤其适合“主表一行对应明细多行”的模型，比如订单、库存流水、日志表，都能用先聚合再关联的方式搞定。
4.3 用EXPLAIN和慢日志定位问题
写复合查询不能只跑通就算完，数据量上来后必须验证性能。我常用的排查顺序是：先开慢查询日志，找到执行时间超过阈值的SQL；再拿这条SQL单独跑一次EXPLAIN，观察执行计划；最后根据key、rows、Extra决定要不要加索引或改写SQL。
慢查询日志的配置很简单：
SET GLOBAL slow_query_log = ON; SET GLOBAL long_query_time = 2;long_query_time单位是秒，生产里通常设置1到3秒，具体看业务容忍度。EXPLAIN不需要真的执行SQL，只是生成执行计划，所以可以放心用。比如：
EXPLAIN SELECT u.id, COUNT(o.id) FROM users u LEFT JOIN orders o ON o.user_id = u.id GROUP BY u.id;如果看到Using join buffer，说明关联时没有有效索引，需要在orders.user_id上建索引；如果看到Using temporary，说明分组或去重使用了临时表，数据量大时很容易拖慢性能。
还有一个容易被忽略的习惯：复合查询里尽量只SELECT需要的字段，别动不动SELECT *。字段越少，排序、分组、临时表处理的成本越低，对ORDER BY和GROUP BY尤为明显。我见过太多慢SQL，其实不是索引问题，而是把一堆用不上的大字段全部拖出来，白白增加IO压力。
5. 一个真实案例：订单统计复合查询从需求到落地
5.1 需求拆解与第一版SQL
假设有这样一个业务需求：统计2024年1月的已支付订单，按用户维度汇总，输出用户昵称、下单次数、订单总金额、购买商品总件数，只保留总金额大于100的用户，按总金额降序排列。
设计表结构如下：
users(id, nickname, created_at) orders(id, user_id, status, total_amount, created_at) order_items(id, order_id, product_id, quantity, price)注意orders.total_amount是订单维度金额，order_items里有quantity和price，但明细金额不要直接用于汇总订单总金额，否则可能出现精度和重复问题。第一版SQL很多新人会这么写：
SELECT u.id AS user_id, u.nickname, COUNT(DISTINCT o.id) AS order_count, SUM(o.total_amount) AS total_amount, SUM(oi.quantity) AS item_count FROM users u LEFT JOIN orders o ON o.user_id = u.id AND o.status = 'paid' AND o.created_at >= '2024-01-01' AND o.created_at < '2024-02-01' LEFT JOIN order_items oi ON oi.order_id = o.id GROUP BY u.id, u.nickname HAVING total_amount > 100 ORDER BY total_amount DESC;这句SQL能跑出结果，但隐藏着严重问题：orders和order_items关联后，一个订单如果有多条明细，total_amount就会重复累加。COUNT(DISTINCT o.id)可以防止下单次数被放大，但SUM(o.total_amount)和SUM(oi.quantity)在数据量变大后很难保证准确。这不是索引问题，而是关联模型问题。
5.2 优化后的写法：先聚合明细，再关联主表
更稳的思路是先把order_items按订单聚合出商品总件数，再和orders关联，这样主表和明细表始终保持一对一的关联状态。MySQL 8.0里用WITH写会更清晰：
WITH order_items_agg AS ( SELECT order_id, SUM(quantity) AS item_count FROM order_items GROUP BY order_id ), order_stat AS ( SELECT o.id, o.user_id, o.total_amount, COALESCE(oi_agg.item_count, 0) AS item_count FROM orders o LEFT JOIN order_items_agg oi_agg ON oi_agg.order_id = o.id WHERE o.status = 'paid' AND o.created_at >= '2024-01-01' AND o.created_at < '2024-02-01' ) SELECT u.id AS user_id, u.nickname, COUNT(*) AS order_count, SUM(os.total_amount) AS total_amount, SUM(os.item_count) AS item_count FROM order_stat os JOIN users u ON u.id = os.user_id GROUP BY u.id, u.nickname HAVING total_amount > 100 ORDER BY total_amount DESC;这里order_items_agg先按订单聚合商品件数，order_stat再按订单表维度准备数据，最后到用户维度做汇总。因为order_stat里每个订单只出现一行，后面的SUM基本不会重复。COALESCE是为了处理没有明细的订单，避免item_count出现NULL。
对应索引建议也不复杂：
ALTER TABLE orders ADD INDEX idx_status_created (status, created_at); ALTER TABLE order_items ADD INDEX idx_order_id (order_id);orders上status和created_at的联合索引能快速过滤出1月已支付订单；order_items上order_id索引能加速明细聚合时的GROUP BY关联。
5.3 这个案例暴露的常见问题
优化后的SQL并不复杂，但如果没有意识到“先聚合再关联”，很容易掉进结果集放大的坑。这个案例里值得记录的还有几个细节。
第一个是金额统计别直接JOIN明细表。total_amount属于主表字段，一旦关联明细表，必须考虑重复累加，最安全的办法是让参与聚合的每行都保持唯一。
第二个是NULL处理要显式。LEFT JOIN关联不到明细时，SUM(quantity)是NULL，直接展示会很难看，所以用COALESCE兜底；同理，HAVING判断的是聚合后的值，不是原始值。
第三个是日期边界用半开区间。2024-01-01 00:00:00到2024-02-01 00:00:00，用>=和<，能正确包含整个1月，避免BETWEEN把2月1日零点这种边界值算进来。
第四个是别在大查询里写SELECT *。这个案例只需要用户ID、昵称、汇总字段，没必要把用户其他字段也拖出来。字段越少，临时表排序越轻，这个优化在复杂聚合SQL里非常有效。
最后分享几个我在实际中形成的小习惯
写完这么多复合查询，我最想强调的是：先保证语义正确，再谈性能。很多人在第一步就写错了JOIN或NULL条件，后面再怎么优化都是白搭。实操里我一般先把业务需求翻译成逻辑草图，标清楚哪一步是过滤原始行、哪一步是关联、哪一步是聚合后过滤，然后才落成SQL。
再有就是不要迷信“子查询一定慢”或者“JOIN一定快”这种结论。不同版本MySQL、不同数据分布下，优化器的选择都不一样。碰到慢查询，老老实实打开执行计划，看key、rows、Extra三个字段，通常问题就水落石出了。复合查询没有秘诀，把一个一个环节拆清楚，结果自然就对了。
