答案：多条件统计必须将case when嵌套在聚合函数内部，如sum(case when...)、count(case when...)，才能单次扫描实现“总销售额”“移动端销售额”“退款订单数”等多列并行计算；where/having仅用于筛选，无法生成新统计列。
多条件统计必须用 CASE WHEN 嵌套在聚合函数里
想在一个查询里同时算出“总销售额”“移动端销售额”“退款订单数”，不能靠拼多条 SQL，也不能靠 HAVING 或 WHERE 拆分——它们只负责筛选，不负责生成新列。真正干活的是把条件判断塞进 SUM()、COUNT() 这些函数内部，让数据库扫一遍数据时就完成多个口径的累加。
常见错误是写 HAVING status = 'completed'，直接报错 Mixing of GROUP columns with no GROUP columns is illegal，因为 status 既没出现在 GROUP BY 里，又没被聚合，数据库根本不知道你指哪一行。
-
COUNT(CASE WHEN status = 'Completed' THEN 1 END)最稳妥：匹配时计 1，不匹配返回 NULL，COUNT()自动跳过 NULL -
SUM(CASE WHEN product_category = 'Electronics' THEN amount ELSE 0 END)要配ELSE 0，否则缺值变 NULL，SUM()会漏加 -
AVG(CASE WHEN order_date >= '2025-06-01' THEN amount END)不需要ELSE：不匹配行自动为 NULL，AVG()本就会忽略 NULL
CASE WHEN 分支的数据类型必须一致
混用类型会触发隐式转换失败，比如 CASE WHEN a THEN 100 ELSE 'N/A' END 在多数数据库里直接报错，因为整数和字符串无法统一类型。聚合函数对类型敏感，尤其 SUM() 和 AVG() 要求数值型，COUNT() 对类型宽容但分支仍需保持逻辑一致。
- 数值类聚合（
SUM、AVG、MAX、MIN）所有分支必须返回数值，或明确转成数值，如CAST(... AS DECIMAL) - 计数类（
COUNT）推荐统一用THEN 1+ELSE NULL，避免用字段名（如THEN order_id），防止字段本身为 NULL 导致误统计 - 字符串类聚合（如某些数据库支持的
STRING_AGG）同理，所有分支必须是字符串或可转串的表达式
WHERE 和 HAVING 的分工不能乱用
WHERE 是扫描前筛行，HAVING 是分组后筛组，两者都干不了“动态产出多列统计”的活。但它们和 CASE WHEN 配合得当，能显著提升性能和可读性。
一款AI工具，主要用于将编码任务调度到本地 OpenAI Codex CLI，支持后台执行、状态轮询以及可交互式回答的澄清问题。适用于 OpenClaw 需要……，适合需要提升相关任务效率的用户。
- 用
WHERE提前过滤掉完全不需要的数据，比如WHERE order_date >= '2025-01-01'，减少后续分组和 CASE 判断的数据量 - 用
HAVING筛掉无意义的组，比如HAVING SUM(amount) > 0，避免返回一堆零值地区 - 别在
WHERE里写product_category = 'Electronics'来替代CASE WHEN——这只会让你丢掉其他品类的数据，没法在同一结果里对比
不同数据库对 FILTER 子句的支持差异很大
PostgreSQL 支持 SUM(amount) FILTER (WHERE product_category = 'Electronics')，写法更简洁；但 MySQL、SQL Server、Oracle 都不支持，硬写会报错。如果团队用多种数据库，或者要写通用脚本，CASE WHEN 是唯一安全选择。
另外，FILTER 不能替代 CASE WHEN 的全部能力——比如你没法用 FILTER 实现 “当 A 成立时取 X，否则当 B 成立时取 Y”，它只支持单层条件过滤；而 CASE WHEN 可嵌套、可组合，逻辑上限更高。
真正容易被忽略的是：所有 CASE WHEN 必须落在聚合函数内部，而不是 SELECT 列表顶层；少一个括号或漏写 END，错误往往不直观，可能只报语法错，也可能静默返回 NULL——得盯紧执行计划和实际结果比对。
