一个 GROUP BY 搞定所有指标？没错，SQL 就是这么设计的。你不需要写一堆子查询、CTE，更不用反复扫描同一张表，直接在同一个 GROUP BY 查询里塞进多个聚合函数，就能一次性完成多指标计算——这是标准 SQL 的原生能力。
为什么一个 GROUP BY 就能算多个指标
数据库优化器比你想象中聪明得多，它会把 COUNT(*)、SUM(amount)、A VG(price)、MAX(created_at) 这些聚合表达式统统塞进同一轮分组过程（比如哈希分组或排序分组）。物理上只读一次表、只做一次分组键匹配，所有指标共享中间结果。
但现实中，很多人偏偏要绕远路。最常见的是写多个 SELECT ... FROM orders GROUP BY region 子查询，再傻乎乎地 JOIN 起来——结果表被反复扫描，性能直线下降。更惨的是，在 MySQL 5.7 中，如果对同一派生表引用两次，直接报错 ERROR 1248: Every derived table must ha ve 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 就万事大吉了，但真正卡住查询性能或导致报错的，往往是隐式依赖和空值处理。
A VG()、SUM()、MAX()会自动忽略NULL，但COUNT(col)也会忽略NULL，而COUNT(*)不忽略——混用时逻辑容易错位，结果可能与你预期完全相反- 当某组内所有
amount都是NULL时，SUM(amount)返回的是NULL，不是0。如果你需要返回0，必须用COALESCE(SUM(amount), 0)处理 - 多列
GROUP BY a, b时，如果a或b中有NULL，它们会被当作独立分组值参与聚合，而不是“合并到一起”
