错误8120表示select中非聚合列未出现在group by子句或未被聚合函数包裹，sql server拒绝模糊输出；修复方式只有两种：将该列加入group by或用sum、max等聚合函数包裹，别无选择。
直接说结论：错误 8120 表示你在 SELECT 列表里写了某个非聚合列（比如 DW_F_SALE_ORDER.ORDER_AMOUNT），但它既没出现在 GROUP BY 子句中，也没被包在 SUM()、AVG() 等聚合函数里——SQL Server 拒绝这种“模糊输出”。
为什么 SELECT 中的列必须进 GROUP BY 或套聚合函数
执行顺序是 FROM → WHERE → GROUP BY → SELECT。到了 SELECT 阶段，数据已按 GROUP BY 分成若干组，每组只允许返回一个确定值。如果某列（如 ORDER_AMOUNT）没参与分组、又没聚合，SQL Server 就不知道该取这组里的哪一行的值——它不猜，直接报错。
- 比如你按
CASE WHEN VIP_SOURCE = '门店' THEN '线下' ELSE '线上' END分组，那每组内可能有几十条订单，ORDER_AMOUNT有几十个不同值 - 你不能直接写
SELECT ..., ORDER_AMOUNT, ...，因为这相当于问：“这一组里到底要哪个ORDER_AMOUNT？” - 必须明确：是要总和？平均？最大？还是干脆按某个逻辑再分组？
修复方式只有两种，别无选择
所有非聚合列，要么加进 GROUP BY，要么用聚合函数包裹。没有第三条路。
- 想保留原始明细级字段（如
ProductID）？那就把它加进GROUP BY列表：GROUP BY Channel, ProductID - 想算整体指标（如客单价）？必须用聚合：把
b.ORDER_AMOUNT改成SUM(b.ORDER_AMOUNT)，把b.QUANTITY改成SUM(b.QUANTITY) - 注意
NULLIF(..., 0)要套在除法分母上，否则除零会崩，不是 8120 的问题但常一起出现 - 别试图用
TOP 1或子查询绕过——只要SELECT里裸露非聚合列，就一定会触发 8120
容易被忽略的嵌套 JOIN 场景
错误可能藏在 JOIN 的子查询里。例如你 LEFT JOIN 了一个已聚合的子查询（如 r 表含 ReturnQty），但在主查询 SELECT 中直接引用了 r.ReturnQty，而主查询的 GROUP BY 并未覆盖 r 的来源维度（如 NumAtCard, ItemCode），照样报 8120。
- 检查所有 JOIN 后的别名表（如
r、c）是否在主GROUP BY中有对应分组依据 - 更稳妥的做法：对这类外部聚合字段也显式聚合，比如写成
MAX(r.ReturnQty)或COALESCE(SUM(r.ReturnQty), 0) - 特别注意
COALESCE(r.ReturnQty, 0)这种写法——r.ReturnQty仍是裸列，不解决根本问题
最麻烦的情况是：你以为子查询已经聚合好了，结果主查询的 GROUP BY 维度比子查询粗（比如子查询按天+商品分组，主查询只按渠道分组），这时必须重新对齐粒度，或改用窗口函数预聚合。这种错不会立刻报 8120，但结果会错得离谱。
