SQL条件聚合：用CASE WHEN一次搞定分组内多维度统计

做数据分析的同行应该都有过这种经历：领导甩过来一张销售表，让我统计"每个门店里，线上支付和线下支付分别贡献了多少销售额"。我第一版用子查询加UNION ALL写，勉强能出结果，但后续每当维度增加一个，SQL就变得又臭又长，后期维护简直是灾难。后来接触了CASE WHEN条件聚合，一个问题只写一条SQL就干净利落地解决了。这篇文章就把这个"分组内统计不同维度总和"的完整思路、实操写法、踩坑经验都整理出来，希望对日常写报表SQL、做数据统计的你有帮助。

1. 需求拆解：为什么"分组内不同维度总和"要用条件聚合

1.1 从一张订单表说起

先看一个最常见的需求。假设我有一张销售订单表，字段包括门店名称、商品品类、支付方式、订单金额，现在要按门店统计线上销售额和线下销售额分别是多少。很多人的第一反应是这么写：

sql复制SELECT store_name, SUM(amount) AS amount
FROM sales_order
WHERE pay_type = 'online'
GROUP BY store_name
UNION ALL
SELECT store_name, SUM(amount) AS amount
FROM sales_order
WHERE pay_type = 'offline'
GROUP BY store_name;

这段SQL能跑出结果，但细看有几个问题。第一，同一家门店会出现在两行数据里，线上线下金额分两行展示，报表层还得自己再做一次行转列处理。第二，如果支付方式有三种、四种，UNION ALL就要写三段、四段，SQL行数成倍增长。第三，这张表被全表扫描了两次，数据量小的时候感觉不出来，一亿行的表跑起来性能差距就非常明显。

条件聚合的思路完全不同：只扫描一次表，通过CASE WHEN在每一行上做判断，把满足不同条件的金额"分流"到不同的聚合列里。这就像我们在Excel里用SUMIFS一样，只不过CASE WHEN是SQL的标准语法，所有主流数据库都认。

1.2 条件聚合的本质：给聚合函数加一个"行级过滤器"

要理解CASE WHEN条件聚合，先得想清楚一个问题：普通的SUM函数是怎么工作的？它是遍历表里所有满足WHERE条件的行，把某一列的值逐行累加。那如果我只想累加其中一部分行呢？传统做法是用WHERE把表拆成多份，分别聚合。条件聚合的做法则是把"是否参与累加"的判断下放到每一行上。

所谓条件聚合，就是让聚合函数在处理每一行时，先通过CASE WHEN判断这一行是否要被计入结果。比如说下面这个表达式：

sql复制SUM(CASE WHEN pay_type = 'online' THEN amount ELSE 0 END)

数据库执行到这一句时，会对每一行做判断：如果pay_type是online，就把amount累加进去，否则加0。这个"逐行判断"就是条件聚合的核心原理。因为是逐行判断，所以它天然适配GROUP BY分组：先按门店分组，再在每个分组里按支付方式分流汇总。

这一点也解释了为什么条件聚合比多次子查询高效。它不需要把同一张表读取多遍，只要一次扫描，在扫描过程中完成所有维度的统计。我自己的体会是，在百万级数据的表上，把三段UNION ALL改成一条条件聚合SQL，执行时间往往能缩短一半以上。

2. CASE WHEN条件聚合的三种核心写法

2.1 基本语法：CASE WHEN的两种形态

CASE WHEN在SQL里有两种书写形态，同样一段逻辑可以用两种方式表达。

第一种是简单CASE表达式，用一个字段和多个值做等值比较：

sql复制CASE pay_type
    WHEN 'online' THEN amount
    WHEN 'offline' THEN amount * 0.9
    ELSE 0
END

第二种是搜索CASE表达式，每个WHEN后面跟一个完整的布尔表达式，适合范围判断：

sql复制CASE
    WHEN pay_type = 'online' THEN amount
    WHEN amount >= 100 THEN amount * 0.8
    ELSE 0
END

从功能上讲，搜索CASE表达式更灵活，支持BETWEEN、LIKE、IN、比较运算等，几乎可以表达任意判断逻辑。实际开发中我大多数情况都用搜索CASE表达式，因为可读性和扩展性都更好，改条件时也不用改动CASE关键词语法结构。

2.2 三种典型模式：求和、计数、求平均

把CASE WHEN放进不同的聚合函数，可以做出不同的统计效果。第一种是求和，这是最常用的模式：

sql复制SUM(CASE WHEN condition THEN value ELSE 0 END)

第二种是计数。注意计数和求和有个关键区别：计数不需要ELSE分支，而是让不满足条件的行返回NULL，让COUNT自动忽略NULL值：

sql复制COUNT(CASE WHEN condition THEN 1 END)

这两种写法我在初学阶段经常搞混。COUNT只统计非NULL值的数量，所以如果不写ELSE，不满足条件的行返回NULL，不会被计数；但如果写了ELSE 0，0是非NULL值，就会把不满足条件的行也统计进去，导致计数结果偏大。

第三种是求平均值。AVG配合CASE WHEN时，不满足条件的行同样建议返回NULL，否则ELSE 0会把0也当成分母的一部分，拉低平均值：

sql复制AVG(CASE WHEN condition THEN value END)

2.3 不同数据库的方言差异：IF函数与CASE WHEN

MySQL里有个IF函数可以当CASE WHEN的简写使用，比如SUM(IF(pay_type='online', amount, 0))，写起来确实省几个字符。但IF函数是MySQL特有的语法，SQL Server、Oracle、PostgreSQL都不支持，换了数据库环境这段SQL直接就报错。

我建议所有打算长期使用的统计SQL都统一写成CASE WHEN标准语法。这不是说IF写法有什么原则性错误，而是从代码可维护性角度考虑。我们做数据平台建设的时候，SQL经常要在不同数据库之间迁移，统一语法能省掉很多改造时间。标准CASE WHEN在所有主流关系型数据库里都是通用的，这个兼容性是IF函数给不了的。

3. 从零到一的实操案例：最常用的四种统计场景

3.1 准备一份示例数据

为了把每种写法讲透，我模拟了一张销售订单表，结构比较简单但覆盖了典型的统计字段。实际工作中，类似的订单表至少会有门店、品类、支付方式、金额、时间这几个维度。

sql复制CREATE TABLE sales_order (
    id INT,
    store_name VARCHAR(50) COMMENT '门店名称',
    category VARCHAR(20) COMMENT '商品品类',
    pay_type VARCHAR(20) COMMENT '支付方式',
    amount DECIMAL(10,2) COMMENT '订单金额',
    order_time DATE COMMENT '下单日期'
);

INSERT INTO sales_order VALUES
(1, '上海店', '数码', 'online', 1200.00, '2024-03-01'),
(2, '上海店', '数码', 'offline', 800.00, '2024-03-01'),
(3, '上海店', '服饰', 'online', 300.00, '2024-03-02'),
(4, '北京店', '数码', 'online', 1500.00, '2024-03-02'),
(5, '北京店', '服饰', 'offline', 500.00, '2024-03-03'),
(6, '北京店', '服饰', 'online', 200.00, '2024-03-03'),
(7, '广州店', '数码', 'offline', 900.00, '2024-03-04'),
(8, '广州店', '服饰', 'online', 400.00, '2024-03-04');

3.2 场景一：按门店统计线上和线下销售额

需求：每个门店线上支付和线下支付的销售总额分别多少。这是"分组内不同维度总和"最直接的诉求。

sql复制SELECT
    store_name,
    SUM(CASE WHEN pay_type = 'online' THEN amount ELSE 0 END) AS online_amount,
    SUM(CASE WHEN pay_type = 'offline' THEN amount ELSE 0 END) AS offline_amount
FROM sales_order
GROUP BY store_name;

执行结果：

对比前面UNION ALL的写法，最大的体感差别是：结果天然就是一行一个门店，线上、线下各占一列，报表层完全不用二次加工。同时每条记录只被读取一次，同一个分组内完成了两个维度的分流。

3.3 场景二：按品类统计不同支付方式的订单量

需求变成统计订单量，而不是金额。这个时候用COUNT配合CASE WHEN，我特别强调不要写ELSE 0：

sql复制SELECT
    category,
    COUNT(CASE WHEN pay_type = 'online' THEN id END) AS online_cnt,
    COUNT(CASE WHEN pay_type = 'offline' THEN id END) AS offline_cnt
FROM sales_order
GROUP BY category;

执行结果：

这里有个细节容易踩坑。有人习惯写成COUNT(CASE WHEN pay_type='online' THEN 1 ELSE 0 END)，从数据结果看，数码的online_cnt会变成4，因为其中一条offline订单也被0填充进了计数。为了把"计数逻辑"和"判断逻辑"解耦，计数场景下我通常连THEN后面的值都懒得指定，THEN 1就够了，不满足时返回NULL。

3.4 场景三：一个分组内同时统计多个品类销售额

需求再升级：每个门店除了要看线上、线下金额，还要分别看数码品类和服饰品类的销售额。这种"一个分组内多个独立维度"的情况，直接写多个SUM(CASE WHEN)即可：

sql复制SELECT
    store_name,
    SUM(CASE WHEN category = '数码' THEN amount ELSE 0 END) AS digital_sales,
    SUM(CASE WHEN category = '服饰' THEN amount ELSE 0 END) AS clothing_sales,
    SUM(amount) AS total_sales
FROM sales_order
GROUP BY store_name;

执行结果：

这里的total_sales是普通的SUM(amount)，对全部分组的行无差别求和，和前面两个维度的条件求和形成互补。实际报表里经常既需要细分子项，又需要看合计，一行SQL就全部拿到了。

3.5 场景四：按年龄分段统计人数分布

工作中还有一类常见需求是把连续值分成区间统计，比如按年龄段统计用户数。CASE WHEN在区间判断上有天然优势：

sql复制SELECT
    CASE
        WHEN age < 18 THEN '18岁以下'
        WHEN age BETWEEN 18 AND 25 THEN '18-25岁'
        WHEN age BETWEEN 26 AND 35 THEN '26-35岁'
        ELSE '36岁以上'
    END AS age_group,
    COUNT(*) AS user_cnt
FROM users
GROUP BY age_group;

这里容易出问题的是GROUP BY后面能不能直接写别名。MySQL和PostgreSQL支持GROUP BY别名，但部分SQL Server版本和Oracle会报错。稳妥的做法是先把分组字段用子查询查出来，再在外面做GROUP BY，或者把整个CASE WHEN表达式复制到GROUP BY后面。

另一个细节是排序。ORDER BY age_group按文本排序的话，"18岁以下"会排在"18-25岁"前面还是后面取决于字符集规则，不一定是业务想要的顺序。我一般会在CASE WHEN里同时输出一个排序字段，比如把age_group_code一起查出来，再ORDER BY age_group_code，这样排序逻辑完全可控。

4. 进阶玩法：多维度交叉统计与行转列

4.1 维度叠加：门店、品类、支付方式三合一统计

统计需求一旦复杂起来，维度往往是交叉叠加的，比如"每个门店每个品类的线上、线下销售额分别是多少"。条件聚合对这类需求依然能打：

sql复制SELECT
    store_name,
    category,
    SUM(CASE WHEN pay_type = 'online' THEN amount ELSE 0 END) AS online_amount,
    SUM(CASE WHEN pay_type = 'offline' THEN amount ELSE 0 END) AS offline_amount
FROM sales_order
GROUP BY store_name, category;

这个写法的执行逻辑是：先把数据按门店和品类组合分组，然后每个分组内部再做线上线下的条件分流。查询结果里每个门店下面会有多行数据，每行对应一个品类，正好满足报表里行列交叉展示的需求。

4.2 行转列：把纵向的维度值变成横向的字段

条件聚合还有一个高频玩法是行转列，也就是把原来纵向存储的维度值变成横向的字段。比如订单表里支付方式是一行一个值，但希望最终输出时online_amount和offline_amount各是一列。前面几个场景已经实现了这个效果，再看一种用MAX而不是SUM的变体：

sql复制SELECT
    store_name,
    MAX(CASE WHEN pay_type = 'online' THEN amount END) AS online_amount,
    MAX(CASE WHEN pay_type = 'offline' THEN amount END) AS offline_amount
FROM sales_order
GROUP BY store_name;

为什么这里用MAX？因为行转列的核心思路是在每个分组内，从满足同一条件的多行里"挑出"那一行对应的值，把它放到对应的列上。MAX是一种"挑选"手段：同一分组下，满足条件的行赋值给MAX，不满足条件的行返回NULL，MAX自然忽略NULL，剩下的就是满足条件的那一行值。这也是做宽表时很标准的姿势。

4.3 百分比计算：让统计结果更直观

统计报表里经常需要算占比，比如线上销售额占总销售额的百分比。条件聚合最大的优势就是分子分母可以在同一条SQL里一次性算出来，不用再单独查一遍总额：

sql复制SELECT
    store_name,
    SUM(CASE WHEN pay_type = 'online' THEN amount ELSE 0 END) AS online_amount,
    SUM(amount) AS total_amount,
    ROUND(SUM(CASE WHEN pay_type = 'online' THEN amount ELSE 0 END) / SUM(amount) * 100, 2) AS online_pct
FROM sales_order
GROUP BY store_name;

执行结果：

需要注意两点。第一，除法运算里如果SUM(amount)为0，会报除零错误，建议用NULLIF或者CASE WHEN先做保护。第二，不同数据库的除法结果类型有差异，MySQL里整型除整型会得到小数，但SQL Server里两个INT相除结果是INT，需要先乘以1.0再除。我通常习惯先乘以100再除，顺手做ROUND保留两位小数，展示更友好。

4.4 条件聚合的性能优势：一次扫描 vs 多次扫描

性能方面，条件聚合最大的优势是"一次扫描、多维度命中"。我们做离线统计时，同一张表可能被多个指标引用，如果用子查询，每个子查询都是一次全表扫描，数据量一大，IO开销成倍增加。条件聚合把判断下放到单行级别，一次扫描就能把多个维度的汇总结果全部算出来。

从执行计划的角度看，条件聚合的SQL通常只有一次TABLE SCAN或INDEX SCAN，加上一次GROUP BY操作；而多个子查询的UNION ALL版本，每个分支都要单独扫描一次表，最后再做UNION去重合并。在亿级数据的表上，这个差异可能从几分钟缩小到几秒钟。

不过要注意，CASE WHEN里的判断条件本身不会直接命中索引，索引是否生效取决于WHERE条件。所以如果只需要统计某段时间或某个门店的数据，先在WHERE里把范围缩小，再在外层做条件聚合，性能会更好。这个先后顺序很多人会搞反。

5. 高频踩坑记录：常见问题与修复方案

5.1 计数统计偏大的罪魁祸首：ELSE 0

前面多次提到，COUNT(CASE WHEN condition THEN 1 ELSE 0 END)会把所有不满足条件的行也通过0值计入统计。我在实际业务中见过好几回这种错误，报表数据就是跟另一个口径复核不上，最后定位到就是这么个细节。

排查办法很简单：先去掉ELSE分支，把写法改成COUNT(CASE WHEN condition THEN 1 END)，让不满足条件的行返回NULL，再对比一次结果。如果前后两次结果不一致，说明原来的写法把ELSE 0也算进去了。这个习惯养成以后，计数类条件聚合基本不会出问题。

5.2 结果出现NULL而不是0

SUM(CASE WHEN ... THEN amount ELSE 0 END)如果某一组里所有满足条件的行都不存在，结果是NULL而不是0。比如某门店当月没有任何线上订单，SUM(online_amount)返回NULL，页面展示就成了空白。为了避免这种情况，我通常会在最外层套COALESCE：

sql复制SELECT
    store_name,
    COALESCE(SUM(CASE WHEN pay_type = 'online' THEN amount END), 0) AS online_amount
FROM sales_order
GROUP BY store_name;

注意这里我把ELSE 0去掉了，同时用COALESCE兜底NULL。两种写法都可行，但语义有区别：ELSE 0是在每行填充0后再累加，COALESCE是聚合完成后再把NULL转成0。数据量小看不出来，但数据量大时去掉ELSE 0能减少一次无意义的累加操作，而且COALESCE的语义更清晰，是"没有数据时显示0"，而不是"用0参与计算"。

5.3 多个CASE WHEN条件重叠导致统计交叉

当一个统计需要多个CASE WHEN分支时，条件之间必须保证互斥，否则数据会被重复计算。比如按金额区间统计高、中、低三档订单数，如果写成：

sql复制CASE WHEN amount >= 100 THEN '高'
CASE WHEN amount <= 500 THEN '低'

那金额200的订单同时满足两个条件，会被算进两个分组里。这种问题定位起来非常隐蔽，因为SQL不报错，结果看起来也有模有样，只有跟业务口径核对时才会露馅。

我的经验是：凡是涉及区间分段的条件，都统一用BETWEEN或者明确的上下限，并让每个条件互斥。条件聚合里CASE WHEN从上到下顺序执行，命中第一个条件后就不再判断后面的分支，这也能用来实现优先级控制。但最好还是在写条件时就保证互斥，而不是依赖顺序，因为后人维护时不一定会注意执行顺序。

5.4 字段类型不一致引发的问题

CASE WHEN判断的字段，类型最好和数据字典保持一致。比如pay_type在表里是字符类型，但写成CASE WHEN pay_type = 1 THEN ...，有的数据库会做隐式类型转换，有的数据库直接报错。即使能跑通，隐式转换也会导致索引失效，性能明显下降。我接手的很多慢SQL里，有一部分就是这种不起眼的类型不匹配引起的。

排查方法也简单：写SQL前先DESC或者看表结构，确认字段类型和取值。如果拿不准取值有哪些，先跑一条SELECT DISTINCT看看实际值长什么样，再做条件聚合。这个习惯能避免很多"统计出来的维度比预想多"的问题。

5.5 GROUP BY别名导致的兼容性问题

GROUP BY后面能不能直接用SELECT里的别名，不同数据库行为不同。MySQL允许，PostgreSQL也允许，但SQL Server和Oracle在某些场景下会报"列名无效"。

为了跨库可移植，我通常不依赖GROUP BY别名，而是把CASE WHEN表达式完整写在GROUP BY里，或者在子查询里先把分组字段算好。两种方式都可读，第二种更清晰，因为子查询把分组逻辑单独隔离了，外层SELECT看起来更干净。

6. 条件聚合的扩展思路：从统计报表到数据处理

条件聚合不只能用在最终统计上，日常数据清洗和判断逻辑里也能发挥很大作用。比如我用它做过订单数据校验：一次扫描判断同一订单是否同时存在多个异常状态，用SUM(CASE WHEN)算出异常数量，再筛选出需要人工复核的数据。这种方法比写多个独立查询再合并，代码量少了一大截，而且逻辑都集中在一处，改规则时只改一个地方。

再比如做宽表加工时，经常要把一个用户的多条行为记录汇总成一行，每个行为类型一列。行转列加上MAX(CASE WHEN)就是最简洁的手段，不需要写存储过程，也不需要做动态SQL。配合GROUP BY直接生成目标宽表，ETL逻辑会清晰很多。

我这里分享一个进阶思路：如果想同时统计每个门店"有线上订单的天数"和"有线下订单的天数"，可以先在子查询里用CASE WHEN给每一天打标，再在外层做COUNT(DISTINCT)：

sql复制SELECT
    store_name,
    COUNT(DISTINCT CASE WHEN pay_type = 'online' THEN order_time END) AS online_days,
    COUNT(DISTINCT CASE WHEN pay_type = 'offline' THEN order_time END) AS offline_days
FROM sales_order
GROUP BY store_name;

这种COUNT(DISTINCT CASE WHEN ...)的模式，把"维度判断"和"去重统计"结合在了一起，在活跃天数、覆盖门店数等指标统计上非常实用。这也是条件聚合真正进阶的用法，当你能熟练组合COUNT、SUM、AVG、COUNT(DISTINCT)和CASE WHEN之后，绝大多数统计报表需求都能用一条SQL优雅表达。

回到文章开头的问题：统计分组内不同维度的总和，最优解就是CASE WHEN条件聚合。它用一次扫描解决多维度统计，既节省了查询时间，又让SQL逻辑集中、可读、易维护。建议你在真实数据上多跑几个场景，把SUM、COUNT、AVG配合CASE WHEN的写法练成肌肉记忆。以后凡是遇到"既要按A分组，又想同时看B、C、D几个维度的统计值"这种需求，第一时间就知道这是条件聚合的拿手好戏。