结论是：用CASE WHEN嵌套在聚合函数里并配合GROUP BY，是实现多条件动态聚合最稳定、兼容性最好的方式；WHERE只能行级过滤，HAVING仅能筛选分组结果，均无法生成多列统计。
直接说结论：用 CASE WHEN 嵌套在聚合函数里，配合 GROUP BY，是实现多条件动态聚合最稳、兼容性最好的方式。别指望靠拼 SQL 或 HAVING 解决这事——它本质是“同一趟扫描里算多个口径”，不是“筛数据”。
为什么不能只靠 WHERE 或 HAVING？
WHERE 在分组前执行，只能筛行，没法表达“这个组里电子产品卖了多少钱”；HAVING 是筛组的，比如“只留平均工资 > 5000 的部门”，但它没法帮你在一个 SELECT 里同时算出“总销售额”“移动端销售额”“退款订单数”三列——因为 HAVING 不产出新列，只决定整组留不留。
常见错误现象：HAVING status = 'completed' 直接报错，提示 Mixing of GROUP columns with no GROUP columns is illegal，原因就是 status 没出现在 GROUP BY 里，又没被聚合，数据库不知道你指哪一行的 status。
- WHERE 适合：提前过滤掉不需要参与分组的记录（如
order_date >= '2025-01-01'） - HAVING 适合：分组后按聚合值筛选（如
HAVING COUNT(*) > 10） - 动态多条件聚合：必须靠
CASE WHEN+ 聚合函数组合实现
CASE WHEN 放在聚合函数里怎么写？
核心写法就是把条件判断塞进 SUM()、COUNT()、AVG() 这些函数内部。数据库扫一遍数据，对每行判断条件是否成立，再决定往哪个聚合桶里扔值。
示例（统计各地区销售明细）：
SELECT region, SUM(amount) AS total_sales, SUM(CASE WHEN product_category = 'Electronics' THEN amount ELSE 0 END) AS elec_sales, COUNT(CASE WHEN status = 'Completed' THEN 1 END) AS completed_cnt, AVG(CASE WHEN order_date >= '2025-06-01' THEN amount END) AS avg_recent_amount FROM orders WHERE order_date >= '2025-01-01' -- 先筛大范围，减少分组数据量 GROUP BY region;
注意点：
-
ELSE 0和ELSE NULL效果不同：SUM()遇NULL会跳过，COUNT()遇NULL也跳过，所以COUNT(CASE WHEN ... THEN 1 END)比COUNT(CASE WHEN ... THEN order_id END)更直白 -
AVG()内部用CASE时，不匹配的行变成NULL，自动被忽略，无需ELSE - 所有
CASE WHEN分支返回的数据类型要一致，否则可能隐式转换失败（比如混用字符串和数字）
如何处理“可选条件”——比如前端没传 region 就不分组？
SQL 本身不支持运行时切换 GROUP BY 字段，所谓“动态分组”实际是两种 SQL 路径：
- 有分组需求：走
GROUP BY region+CASE WHEN聚合 - 无分组需求：去掉
GROUP BY，用全表聚合，如SELECT SUM(amount), COUNT(*) FROM orders
不能靠一条 SQL 同时满足“按 region 分组”和“不分组汇总”。硬写成 GROUP BY COALESCE(#{region}, '') 会导致所有无 region 的记录被归为一组，语义错乱。更稳妥的做法是后端根据参数存在与否，生成不同 SQL 模板：
- region 参数非空 → 拼
GROUP BY region - region 参数为空 → 不写
GROUP BY，也不选 region 字段
避免踩坑：别用 GROUP BY IFNULL(#{region}, 'all') 这类写法，它会让“未指定 region”的结果和真实 region='all' 的数据无法区分。
性能与兼容性要注意什么？
CASE WHEN 方案在 MySQL、PostgreSQL、SQL Server、Oracle 上都原生支持，没有语法差异，是最安全的选择。但有两点容易被忽略：
- 索引仍然只对
WHERE条件生效，CASE WHEN里的字段不会走索引——所以务必把强过滤条件（如时间范围、状态码）放在WHERE里，而不是塞进CASE - 当
CASE WHEN分支过多（比如 10+ 个分类），部分旧版 MySQL（UNION ALL 显式拆解
真正麻烦的不是写法，而是“可选”这件事本身——它意味着业务逻辑要明确区分“不分组汇总”和“按某维度分组”，这两者在语义和结果结构上根本不同，强行用一条 SQL 去覆盖，迟早会在分页、排序、NULL 处理上出问题。
