SQL Server关联查询聚合子查询问题：分组后金额不符排查

兄弟，我太懂这种明明逻辑看起来没问题，但结果就是不对的抓狂感了！针对你说的333-222金额跑出30而非预期10的问题，结合这类拆分表匹配的常见坑，你大概率忽略了这几个关键细节：

1. 分组时漏了拆分维度，导致错误累加 #

我猜你的拆分表（就是被拆成多行的那张）里，333-222对应的是3行金额为10的记录？如果直接按ID分组SUM(Amount)，那结果肯定是30，但这些拆分行应该是对应主表同一条记录的不同拆分维度（比如按业务批次、费用类型拆分），你没把这些维度加入分组条件，就会把所有拆分行的金额无脑加总，而不是匹配到主表对应的单条记录金额。

举个反例（你可能写的就是这个）：

SELECT ID, SUM(Amount) AS TotalAmount
FROM SplitTable
GROUP BY ID

正确的做法是把拆分的标识字段（比如BatchNo、SplitType这类）加入分组，确保每个分组对应主表的一条记录：

SELECT ID, SplitKey, SUM(Amount) AS TotalAmount
FROM SplitTable
GROUP BY ID, SplitKey

之后再用ID + SplitKey和主表关联，就能拿到每个拆分组对应的正确金额了。

2. 关联条件太宽泛，触发了笛卡尔积 #

如果你的关联逻辑只靠ID连接两张表，那主表的一条333-222记录，会和拆分表的3条同ID记录一一关联，这时候如果再做聚合，就会把拆分表的3个10累加起来。本质是你没明确拆分表的每行该对应主表的哪部分（或者说，拆分表的多行其实是主表同一条记录的冗余存储，而非拆分）。

比如你可能写了这样的关联查询：

SELECT m.ID, m.Amount AS Expected, SUM(s.Amount) AS Actual
FROM MainTable m
JOIN SplitTable s ON m.ID = s.ID
GROUP BY m.ID, m.Amount

这时候主表的1条记录和拆分表3条记录关联，自然会算出30。如果拆分表的多行是冗余（而非拆分金额），那你应该用MAX(s.Amount)/MIN(s.Amount)代替SUM，或者用DISTINCT去重后再关联。

3. 对拆分表的金额逻辑理解错了 #

还有一种可能：你以为拆分表的每行是主表金额的拆分部分（比如10拆成3+3+4），但实际上拆分表的每行都是完整的主表金额拷贝。这时候你根本不该用SUM，而是取任意一行的金额就行，比如用MAX(Amount)或者直接TOP 1。

快速验证方法 #

先查下拆分表中333-222的所有数据，看看金额到底是啥情况：

SELECT * FROM SplitTable WHERE ID = '333-222'

如果结果是3行10，那就是聚合方式或分组维度的问题；如果是拆分后的金额，那就是关联条件没匹配到正确的对应关系。

内容的提问来源于stack exchange，提问作者Ryan Gadsdon