sum(case when...)比count(case when...)更灵活，因sum直接累加数值（如1或0），语义清晰且支持加权；而count统计非null行数，若误写else 0会导致所有行被计数，结果偏大，且不支持金额等数值聚合。

为什么SUM(CASE WHEN ...)比COUNT(CASE WHEN ...)更灵活

因为SUM天然处理数值，而CASE WHEN返回的每行结果可以是0、1或任意数字，直接累加即可；COUNT只统计非NULL行数，遇到ELSE 0会把0当有效值计数，导致结果偏大——除非显式写ELSE NULL，但多数人会忽略这点。

常见错误现象：COUNT(CASE WHEN status = 'paid' THEN 1 END)能用，但一旦写成COUNT(CASE WHEN status = 'paid' THEN 1 ELSE 0 END)，所有行都被计入，结果变成总行数。

• 真正想做条件计数，优先用SUM(CASE WHEN ... THEN 1 ELSE 0 END)，语义清晰且不怕漏写ELSE
• 需要加权求和（比如不同状态对应不同金额系数）时，SUM是唯一选择：SUM(CASE WHEN type = 'vip' THEN amount * 1.2 ELSE amount END)
• MySQL 8.0+ 支持IF()，但跨数据库兼容性差，CASE WHEN是通用解法

聚合前必须GROUP BY吗？不加会怎样

不加GROUP BY时，SUM(CASE WHEN ...)会对整张表计算一个汇总值，相当于全表扫描后返回单行结果。加上GROUP BY才按维度拆分统计——这是初学者最常混淆的点。

典型错误：在订单表里写SELECT user_id, SUM(CASE WHEN paid = 1 THEN 1 ELSE 0 END) FROM orders;，MySQL 5.7+会报错Expression #1 of SELECT list is not in GROUP BY clause，因为user_id没参与聚合也没被分组。

• 要按用户统计付款订单数：SELECT user_id, SUM(CASE WHEN paid = 1 THEN 1 ELSE 0 END) AS paid_cnt FROM orders GROUP BY user_id
• 要查全表付款率：SELECT SUM(CASE WHEN paid = 1 THEN 1 ELSE 0 END) * 1.0 / COUNT(*) AS rate FROM orders，这里不需要GROUP BY
• PostgreSQL 对非GROUP BY字段更严格，连SELECT *都禁止，务必检查字段是否全部出现在GROUP BY或聚合函数中

NULL值怎么影响CASE WHEN的结果

CASE WHEN里条件判断遇到NULL一律返回FALSE（不是报错），所以WHEN col = 'x'对col IS NULL的行完全不匹配，最终走ELSE分支。如果没写ELSE，默认为NULL，而SUM会忽略NULL值——这会导致结果偏低，且难以排查。

例如：SUM(CASE WHEN category = 'A' THEN 1 END)在category有NULL时，这些行既不进THEN也不进ELSE，等价于SUM(CASE WHEN category = 'A' THEN 1 ELSE NULL END)，而SUM(NULL)不参与累加。

• 保险写法永远带ELSE 0：SUM(CASE WHEN category = 'A' THEN 1 ELSE 0 END)
• 想单独统计NULL行数量：SUM(CASE WHEN category IS NULL THEN 1 ELSE 0 END)
• 避免用= NULL判断，必须用IS NULL，否则条件恒为UNKNOWN，结果不可预期

性能要注意哪些实际细节

数据库优化器通常能把SUM(CASE WHEN ...)识别为单次扫描，和普通SUM()性能接近，但有几个硬伤点容易拖慢：

• WHERE条件没走索引时，全表扫描不可避免，CASE逻辑本身不加重负担，但数据量大时IO是瓶颈
• 在ORDER BY或HAVING里重复写相同CASE表达式（如HAVING SUM(CASE WHEN ...)=0），部分旧版MySQL不会复用中间结果，建议用子查询或CTE提取
• 字符串字段做CASE WHEN判断时，注意大小写敏感性：MySQL默认不区分，PostgreSQL区分，必要时显式加LOWER()或使用ILIKE
• 别在SELECT里写多个独立的SUM(CASE WHEN ...)去统计不同条件——只要逻辑不冲突，尽量合并到一个CASE里用不同分支，减少解析开销

真正难的不是语法，是想清楚“这一行该不该被某个条件捕获”，以及“空值、边界值、类型隐式转换”会不会悄悄改变CASE的分支走向。