CASE WHEN必须嵌套在聚合函数内，因SQL执行顺序为先GROUP BY后SELECT，若置于顶层且未聚合，会因非聚合字段未出现在GROUP BY中而报错；正确写法是COUNT(CASE WHEN condition THEN 1 END)。
GROUP BY 本身不执行逻辑判断，它只负责分组；所有“复杂逻辑”必须靠 CASE WHEN 套在聚合函数里、或提前用子查询/CTE 打标签来实现。
为什么不能直接在 SELECT 顶层写 CASE WHEN 然后 GROUP BY？
因为 SQL 执行顺序是 GROUP BY 先于 SELECT，分组完成后每组只剩一行，CASE WHEN 若没嵌套在聚合函数中，就会变成对单行值做判断——但该字段又没出现在 GROUP BY 列表里，直接报错。
- 错误写法：
SELECT dept, CASE WHEN salary > 8000 THEN 'high' END, COUNT(*) FROM emp GROUP BY dept→ 报错：非聚合字段CASE WHEN不在GROUP BY - 正确写法：
SELECT dept, COUNT(CASE WHEN salary > 8000 THEN 1 END) AS high_cnt FROM emp GROUP BY dept -
CASE WHEN必须作为COUNT/SUM/AVG的参数，才能在每组内逐行判断、再汇总
多条件组合判断怎么写进聚合？
把业务逻辑拆成布尔表达式，用 CASE WHEN 转成可聚合的值（如 1/0、数值、字符串），再套聚合函数。
- 统计“当月新增且当月支付”的订单数：
COUNT(CASE WHEN YEAR(create_time) = YEAR(pay_time) AND MONTH(create_time) = MONTH(pay_time) THEN 1 END) - 注意
pay_time IS NULL要显式排除，否则整行被跳过；可写成CASE WHEN pay_time IS NOT NULL AND ... THEN 1 END - 避免混用不同时间粒度字段直接比较，比如
create_time >= '2024-06-01' AND pay_time —— 这会漏掉跨月成交的订单
GROUP BY 配合 HAVING 怎么做逻辑筛选？
HAVING 只能筛分组后的结果，条件里必须含聚合函数或分组字段；它不是万能过滤器，不能替代 WHERE 做行级判断。
- 要查“订单数 ≥ 3 且平均金额 > 500”的客户：
HAVING COUNT(*) >= 3 AND AVG(amount) > 500 - 不能写
HAVING status = 'paid'—— 这是单行条件，得放WHERE里 - LEFT JOIN 后想筛“有至少 2 笔已付款订单”的用户，必须先
GROUP BY u.id，再HAVING COUNT(CASE WHEN o.status = 'paid' THEN 1 END) >= 2 -
COUNT(o.id)自动忽略NULL（即没匹配到订单的用户记为 0），而COUNT(*)会把空行算作 1 —— 选错就漏数据
复杂表达式分组时容易踩什么坑？
GROUP BY 不认别名，也不自动推导语义；所有用于分组的表达式，必须在 GROUP BY 子句里原样重复。
- 按年月分组：
GROUP BY YEAR(order_date), MONTH(order_date)，不能写GROUP BY order_year（即使前面SELECT用了AS order_year） - 字符串拼接分组：
GROUP BY CONCAT(LEFT(name, 1), '-', dept)，不能用别名替代 - MySQL 在宽松模式下可能允许别名，但 PostgreSQL/Oracle/SQL Server 全部拒绝 —— 生产环境别赌兼容性
- 推荐用 CTE 预处理：
WITH grouped AS (SELECT ..., YEAR(order_date) AS y, MONTH(order_date) AS m FROM orders) SELECT y, m, SUM(amount) FROM grouped GROUP BY y, m
真正难的不是语法，而是厘清“判断发生在哪一层”：行级逻辑放 WHERE 或子查询，组内计算放 CASE WHEN + 聚合函数，组间筛选放 HAVING。一旦混淆层级，结果就不可靠。
