一个 GROUP BY 可同时计算多个聚合指标，因优化器将 COUNT(*)、SUM(amount) 等合并为单次分组扫描；非聚合字段须显式写入 GROUP BY；条件统计统一用 CASE WHEN；NULL 值需注意各函数处理差异。
直接在同一个 GROUP BY 查询里写多个聚合函数，就能一次性完成多指标计算——这是标准 SQL 的原生能力，不需要子查询、CTE 或多次扫描。
为什么一个 GROUP BY 就能算多个指标
数据库优化器会把 COUNT(*)、SUM(amount)、AVG(price)、MAX(created_at) 这些聚合表达式合并进同一轮分组过程（比如哈希分组或排序分组）。物理上只读一次表、只做一次分组键匹配，所有指标共享中间结果。
常见错误现象：
– 写了多个 SELECT ... FROM orders GROUP BY region 子查询再 JOIN，导致表被反复扫描
– 在 MySQL 5.7 中对同一派生表引用两次，直接报错 ERROR 1248: Every derived table must have its own alias
- 所有非聚合字段（如
region）必须显式出现在GROUP BY列表中，否则 PostgreSQL / MySQL 8.0+ 会报ERROR 1140 - 聚合函数之间互不干扰，可自由混用，但不能嵌套（如
COUNT(SUM())语法非法） - 大表或高并发下，反复扫描的 I/O、加锁、执行计划解析开销远高于单次内存分组
COUNT 条件统计必须用 CASE WHEN，别信 MySQL 的布尔返回值
MySQL 允许写 COUNT(status = 'success')，但它实际返回的是行数（因为 status = 'success' 是布尔表达式，在 COUNT 中被转为 1/0，而 COUNT() 统计非 NULL 值），不是你想要的“成功订单数”。语义不清且跨数据库不可移植。
- 正确写法统一用：
COUNT(CASE WHEN status = 'success' THEN 1 END) -
SUM(CASE WHEN ... THEN 1 ELSE 0 END)虽结果等价，但优化器更难识别其计数意图 - PostgreSQL 可用更清晰的
COUNT(*) FILTER (WHERE status = 'success')，但 MySQL / SQL Server / Oracle 不支持，得回退到CASE WHEN
不同时间窗口或业务条件的指标，仍要单扫
比如要同时统计“近7天订单数”和“近30天复购用户数”，不能靠外层加 WHERE 分两次查——那等于两次全表扫描。必须把过滤逻辑下沉到聚合内部。
- MySQL 写法：
COUNT(CASE WHEN created_at >= DATE_SUB(CURDATE(), INTERVAL 7 DAY) THEN 1 END) AS week_orders - PostgreSQL 写法：
COUNT(*) FILTER (WHERE created_at >= current_date - 7) AS week_orders - 避免写成
SUM(IF(..., 1, 0))：函数语义是求和，不是计数，部分优化器无法做聚合识别优化
容易被忽略的关键点
很多人以为只要写了 GROUP BY 就万事大吉，但真正卡住查询性能或导致报错的，往往是隐式依赖和空值处理。
-
AVG()、SUM()、MAX()自动忽略NULL，但COUNT(col)也忽略NULL，而COUNT(*)不忽略——混用时逻辑容易错位 - 当某组内所有
amount都为NULL，SUM(amount)返回NULL，不是0；需要补COALESCE(SUM(amount), 0) - 多列
GROUP BY a, b时，若a或b有NULL，它们会被当作独立分组值参与聚合，不是“合并到一起”
