CASE WHEN 必须写在聚合函数内，因为SQL先执行GROUP BY分组，再计算聚合值；若置于SELECT顶层且未嵌套聚合函数，会因非聚合字段未出现在GROUP BY中而报错。
GROUP BY 遇到多条件判断，为什么 CASE WHEN 必须写在聚合函数里？
因为 SQL 的执行顺序是先 GROUP BY 分组，再对每组计算聚合值；CASE WHEN 如果写在 SELECT 顶层但没套聚合函数，就会报错“不在 GROUP BY 子句中”或“invalid use of group function”。它不是过滤器，而是分组内的逻辑分支表达式。
- 错误写法：
SELECT department, CASE WHEN salary > 5000 THEN 'high' ELSE 'low' END, COUNT(*) FROM emp GROUP BY department→ 报错：非聚合字段不能出现在 SELECT 中（除非也在 GROUP BY 里） - 正确写法：
SELECT department, COUNT(CASE WHEN salary > 5000 THEN 1 END) AS high_count, COUNT(CASE WHEN salary -
CASE WHEN在聚合内部才真正“按行判断、按组汇总”，外面套COUNT/SUM/AVG才有意义
统计带状态流转的指标，比如“本月新增且当月成交客户数”，CASE WHEN 怎么嵌套时间条件？
关键不是嵌套多深，而是所有判断条件必须基于同一行数据。如果要算“新增+成交”，就得确保两个动作发生在同一条记录里，或者用子查询/窗口函数先打标签——直接在 CASE 里混用不同时间维度的字段（比如 create_time 和 pay_time）容易漏掉跨月行为。
- 安全做法：先用子查询或 CTE 标记每条订单是否“当月新增且当月支付”，再分组统计：
SELECT status_tag, COUNT(*) FROM (SELECT *, CASE WHEN YEAR(create_time)=YEAR(pay_time) AND MONTH(create_time)=MONTH(pay_time) THEN 'new_and_paid' ELSE 'other' END AS status_tag FROM orders) t GROUP BY status_tag - 避免陷阱：不要写
CASE WHEN create_time >= '2024-06-01' AND pay_time —— 这会把 create_time 是 5 月但 pay_time 在 6 月的订单也筛进来，逻辑错位 - 注意 NULL：
pay_time可能为空，CASE WHEN pay_time IS NOT NULL AND ...必须显式判断，否则整行被跳过
用 SUM(CASE WHEN ...) 还是 COUNT(CASE WHEN ...)？区别在哪？
本质是“计数逻辑”不同：COUNT 统计非 NULL 值个数，SUM 求和。当 CASE 返回 1/0 时两者结果一样；但若返回具体数值（如金额、权重），就必须用 SUM。
- 统计人数：用
COUNT(CASE WHEN score >= 90 THEN 1 END)或SUM(CASE WHEN score >= 90 THEN 1 ELSE 0 END)都行，但前者更直观 - 统计金额：必须用
SUM(CASE WHEN status = 'paid' THEN amount ELSE 0 END)，不能用COUNT，否则丢掉数值信息 - 性能差异极小，但语义清晰更重要：该求和就别硬套计数，尤其涉及浮点或大数时，
COUNT强制转整型可能截断
MySQL 5.7 vs PostgreSQL vs ClickHouse，CASE WHEN 在聚合里的行为一致吗？
语法层面基本一致，但 NULL 处理和类型推导有细微差别，尤其在混合类型时容易翻车。
- MySQL 5.7：
CASE WHEN a>1 THEN 'yes' ELSE 123 END会把整数 123 转成字符串，但某些版本报 warning；建议统一返回同类型，或显式CAST - PostgreSQL：严格类型检查，
THEN 'yes' ELSE 123直接报错，必须写ELSE CAST(123 AS TEXT)或都用字符串 - ClickHouse：支持
multiIf替代长CASE，性能更好，但CASE本身不支持在聚合外裸用（会提示 “ILLEGAL_TYPE_OF_ARGUMENT”） - 通用建议：所有分支返回相同数据类型；复杂逻辑优先抽到子查询里，别堆在聚合层
CASE WHEN 写得再准也没用。 
