在关系型数据库里，多对多关联是非常常见的建模方式，比如用户和角色、订单和优惠券、商品和标签。但当我们需要基于这类结构做聚合统计时，如果直接把多张表JOIN起来再GROUP BY，经常会发现SUM、COUNT的结果比真实值大好几倍。这一现象并不是数据库算错了，而是连接操作本身把行数放大了，聚合函数自然就在放大的结果集上进行计算。
要理解统计翻倍，我们先看一个具体场景。假设有两张表：order表记录订单基础信息，order_item表记录订单中的商品明细，而product_tag表通过中间表item_tag_rel与order_item形成多对多关系。当我们想统计每个订单的金额以及它关联了多少个去重标签时，新手很容易写出下面这样的SQL。
一、直接JOIN导致的统计翻倍问题
下面这段代码把订单、明细、标签关系全部连在一起，然后按订单分组统计。因为同一个订单项可能对应多个标签，三表JOIN后订单项的行数会被标签数量复制，从而导致金额被重复累加。
SELECT
o.order_id,
SUM(oi.price * oi.qty) AS total_amount,
COUNT(DISTINCT pt.tag_id) AS tag_cnt
FROM `order` o
JOIN order_item oi ON o.order_id = oi.order_id
JOIN item_tag_rel rel ON oi.item_id = rel.item_id
JOIN product_tag pt ON rel.tag_id = pt.tag_id
GROUP BY o.order_id;
假设订单A有2个商品项，其中一项关联了3个标签，另一项关联了2个标签，那么JOIN后的中间结果中，订单A原本2行的明细会变成5行。SUM函数在这5行上累加价格，金额就变成真实值的多倍。虽然COUNT(DISTINCT)能勉强保证标签数不错，但金额已经完全失真。
这种写法的另一个隐患是性能。多表JOIN产生的临时结果集可能非常庞大，尤其在标签表数据量增长后，数据库需要先物化一个膨胀的中间表再分组，磁盘和内存开销都很高。很多慢查询就是这样来的，并不是索引没建，而是SQL结构本身引发了数据放大。
二、使用子查询先汇总再JOIN连接
解决思路很直接：不要让多端数据在JOIN阶段放大，而是先在子查询里按外键把多端聚合成单行指标，再拿汇总结果去关联其他表。这样每次JOIN都是一对一或一对少的稳定关系，聚合基数不会失控。
SELECT
o.order_id,
item_sum.total_amount,
tag_sum.tag_cnt
FROM `order` o
JOIN (
SELECT
order_id,
SUM(price * qty) AS total_amount
FROM order_item
GROUP BY order_id
) item_sum ON o.order_id = item_sum.order_id
JOIN (
SELECT
oi.order_id,
COUNT(DISTINCT pt.tag_id) AS tag_cnt
FROM order_item oi
JOIN item_tag_rel rel ON oi.item_id = rel.item_id
JOIN product_tag pt ON rel.tag_id = pt.tag_id
GROUP BY oi.order_id
) tag_sum ON o.order_id = tag_sum.order_id;
在上面的SQL中，第一个子查询item_sum先把订单明细按订单汇总出金额，每个订单只有一行；第二个子查询tag_sum在明细和标签的关联范围内先去重统计标签数，同样每个订单一行。主查询只是把订单表和这两个已经压平的结果做JOIN，不存在行数放大，SUM和COUNT都基于正确基数。
这种写法还有一个好处是可维护性强。如果后续要加一个按店铺汇总的逻辑，只需要在对应子查询里调整GROUP BY字段，主查询结构不变。相比把全部逻辑揉在一个多层JOIN里，子查询先汇总的方式更符合分而治之的思想，也方便DBA阅读执行计划，定位到底是哪一步扫描行数异常。
三、方案对比与注意事项
除了子查询预汇总，有些人会用窗口函数或者外层DISTINCT来规避翻倍。比如先JOIN再用SUM(price) OVER(PARTITION BY order_id)，但窗口函数仍基于膨胀后的行，要去重还得配合子查询，反而更复杂。下表列出几种常见处理方式的差异。
| 处理方式 | 统计准确性 | 性能表现 | 可读性 |
|---|---|---|---|
| 直接多表JOIN后GROUP BY | 金额易翻倍 | 中间集大，易慢 | 乍看简单，实则隐蔽坑 |
| 子查询先汇总再JOIN | 基数正确 | 索引命中好，稳定 | 结构清晰，易扩展 |
| 外层DISTINCT或窗口函数补救 | 需谨慎写才正确 | 临时表仍膨胀 | 逻辑绕，难排查 |
使用子查询先汇总时，要注意子查询里的GROUP BY字段必须和主表JOIN键完全一致，否则会出现订单丢失或笛卡尔放大。另外，如果汇总子查询返回的是左连接语义，主查询应使用LEFT JOIN来保留没有明细的订单，避免统计时把空订单误删。
在真实业务里，报表类SQL往往关联七八张表，遵循先聚合后连接的原则，可以显著降低统计翻车的几率。把多对多关系拆成独立的汇总单元，不仅是写法的优化，更是对数据模型关系的准确表达。
四、完整可运行示例
下面给出一个包含建表与数据的MySQL示例，方便你在本地验证子查询汇总的效果。注意其中的HTML特殊字符已转义，标签名仅作说明。
CREATE TABLE `order` (
order_id INT PRIMARY KEY,
buyer VARCHAR(20)
);
CREATE TABLE order_item (
item_id INT PRIMARY KEY,
order_id INT,
price DECIMAL(10,2),
qty INT
);
CREATE TABLE product_tag (
tag_id INT PRIMARY KEY,
tag_name VARCHAR(20)
);
CREATE TABLE item_tag_rel (
item_id INT,
tag_id INT
);
INSERT INTO `order` VALUES (1, '张三');
INSERT INTO order_item VALUES (10, 1, 100.00, 2), (11, 1, 50.00, 1);
INSERT INTO product_tag VALUES (1, '促销'), (2, '新品'), (3, '热卖');
INSERT INTO item_tag_rel VALUES (10, 1), (10, 2), (10, 3), (11, 1);
SELECT
o.order_id,
item_sum.total_amount,
tag_sum.tag_cnt
FROM `order` o
JOIN (
SELECT order_id, SUM(price * qty) AS total_amount
FROM order_item GROUP BY order_id
) item_sum ON o.order_id = item_sum.order_id
JOIN (
SELECT oi.order_id, COUNT(DISTINCT pt.tag_id) AS tag_cnt
FROM order_item oi
JOIN item_tag_rel rel ON oi.item_id = rel.item_id
JOIN product_tag pt ON rel.tag_id = pt.tag_id
GROUP BY oi.order_id
) tag_sum ON o.order_id = tag_sum.order_id;
-- 正确结果：total_amount = 250.00，tag_cnt = 3
运行上述脚本，你会看到订单1的金额是250而不是因为标签关联被放大成750，标签数也正确地去重为3。这证明了子查询先汇总再JOIN确实是处理多对多统计翻倍的有效手段。
当面对更复杂的嵌套多对多，比如订单下商品关联标签、商品又关联供应商分类，可以继续沿用该模式：从最底层的多端关系开始，逐层向上用子查询聚合成单行，最后在主查询里做窄连接。只要守住连接前先压平的原则，统计逻辑就不会被行数膨胀带偏。