一个 GROUP BY 可同时计算多个聚合函数，因优化器会合并扫描与分组过程；应避免多查询 JOIN 或子查询，而用 CASE WHEN 实现条件统计，并注意 COUNT(DISTINCT) 与 GROUPING SETS 的适用场景及兼容性。
单个 GROUP BY 就能合并多个 SUM 和 COUNT 的扫描，不需要子查询或 UNION——这是数据库优化器的默认行为，前提是写法正确。
为什么一个 GROUP BY 能同时算多个聚合
数据库（MySQL 8.0+、PostgreSQL、SQL Server）在执行 GROUP BY 时，会把 COUNT(*)、SUM(amount)、AVG(price) 等聚合表达式合并进同一轮分组过程。物理上只读一次表、只做一次哈希/排序分组，所有指标共享中间分组键和行数据。
常见错误现象：
- 写三个独立的
SELECT ... GROUP BY再用JOIN合并——表被扫三遍，I/O 和锁开销翻倍 - 用子查询分别算
total_count和paid_sum，再FROM (sub1) JOIN (sub2)——派生表无索引，JOIN 成瓶颈
正确做法就是直接在同一个 SELECT 里写多个聚合函数：
SELECT region, COUNT(*) AS total_orders, COUNT(CASE WHEN status = 'paid' THEN 1 END) AS paid_count, SUM(amount) AS total_amount, SUM(CASE WHEN status = 'paid' THEN amount ELSE 0 END) AS paid_amount FROM orders GROUP BY region;
COUNT 条件统计必须用 CASE WHEN，别信 COUNT(status = 'paid')
MySQL 允许写 COUNT(status = 'paid')，但它实际统计的是布尔表达式非 NULL 的行数（即所有行），不是“已支付订单数”。语义模糊，且在 PostgreSQL 或 SQL Server 中会报错。
统一用标准写法：
-
COUNT(CASE WHEN status = 'paid' THEN 1 END)—— 统计符合条件的行数，NULL 自动被COUNT忽略 -
SUM(CASE WHEN status = 'paid' THEN amount ELSE 0 END)—— 注意是ELSE 0，避免SUM返回 NULL - 别用
SUM(IF(...))：函数语义是求和，优化器难识别为条件计数，部分场景无法下推过滤
多个 COUNT(DISTINCT) 同时计算的陷阱
要同时统计“总用户数”“iOS 用户数”“付费用户数”，如果写成：
COUNT(DISTINCT user_id), COUNT(DISTINCT CASE WHEN os = 'iOS' THEN user_id END), COUNT(DISTINCT CASE WHEN paid_at IS NOT NULL THEN user_id END)
——这是安全且高效的做法。现代优化器（如 MySQL 8.0+、PostgreSQL 14+）能复用同一轮去重逻辑。
但要注意：
- 不能写成
COUNT(DISTINCT user_id) FILTER (WHERE os = 'iOS')：仅 PostgreSQL 支持，MySQL 不认 - 如果字段本身允许 NULL，
COUNT(DISTINCT col)会自动跳过 NULL，无需额外处理 - 大表上仍建议给
user_id加索引，否则去重过程内存压力大
GROUPING SETS 适合多维汇总，但别滥用
当你要同时按 (country)、(country, province)、(country, province, city) 三层分组汇总，用 GROUPING SETS 可避免三次扫描：
SELECT country, province, city, SUM(sales) AS total_sales FROM sales_data GROUP BY GROUPING SETS ( (country), (country, province), (country, province, city) );
但要注意：
- 返回结果中未参与当前分组的列值为
NULL，业务层需识别（比如province IS NULL表示国家级汇总） - MySQL 直到 8.0.29 才支持
GROUPING SETS，旧版本得回退到UNION ALL+ 多个GROUP BY - 它不解决“单维度内多条件聚合”，只是“多个维度组合”的语法糖，别和
CASE WHEN混用错场景
真正容易被忽略的点是：聚合逻辑是否能提前固化。比如“活跃用户”的定义一旦变更（从“7日内登录”变成“30日内下单”），所有预聚合、物化视图、GROUPING SETS 查询都得同步调整——性能优化的前提，是业务口径足够稳定。
