因为case when本身不聚合，必须配合group by和聚合函数（如sum、max）才能压缩多行数据为一行，否则结果会按原始行数展开，导致重复、空值多或总数错误。
为什么直接用 CASE WHEN 做行转列容易漏数据？
因为 CASE WHEN 本身不聚合，如果源表存在多行匹配同一分组（比如一个用户有多条订单记录），不做 GROUP BY + 聚合函数，结果会按原行数展开，看起来像“没转成功”。常见现象是：列名对了，但值重复、空值多、总数不对。
正确姿势是把 CASE WHEN 当作表达式嵌入聚合函数里，例如：SUM(CASE WHEN ... THEN value ELSE 0 END) 或 MAX(CASE WHEN ... THEN value END)。选哪个聚合函数取决于业务逻辑——要累加用 SUM，要取最新/非空值用 MAX 或 COALESCE(MAX(...), ...)。
- 必须配
GROUP BY，且分组字段是“行变列后想保留的维度”，比如user_id、date -
ELSE分支不能省略，否则匹配不到的行会变成NULL，影响SUM/COUNT结果 - 字符串类字段慎用
SUM，应改用MAX或GROUP_CONCAT
CASE WHEN 中条件写错导致列值全为 NULL 怎么排查？
典型错误是条件表达式类型不匹配或隐式转换失败，比如用 status = '1' 对比整型字段 status（实际存的是 INT），MySQL 可能不报错但永远不命中。另一个高发场景是空格或大小写——category = 'mobile' 匹配不了 'Mobile '。
实操建议：
- 先单独查出所有可能的原始值：
SELECT DISTINCT category FROM orders;看真实数据长什么样 - 用
TRIM()和LOWER()统一处理再比对，比如CASE WHEN LOWER(TRIM(category)) = 'mobile' THEN amount END - 避免在
WHEN中调用函数处理字段（如WHEN YEAR(create_time) = 2023），会导致索引失效；应提前算好衍生字段或用范围条件替代
多个 CASE WHEN 并列时性能突然变差怎么办？
当一行里写十几个 CASE WHEN 表达式，尤其每个都含子查询或复杂函数，MySQL 会为每列重复执行判断逻辑，CPU 和临时表压力陡增。不是语法错，是执行计划崩了。
优化方向很实在：
- 把共用的判断逻辑提取成派生列，例如先
SELECT ..., CASE WHEN type IN (1,2,3) THEN 'A' WHEN type IN (4,5) THEN 'B' END AS group_flag FROM t，再在外层按group_flag分列 - 确认是否真需要“宽表”——有时用应用层拼装（查出明细再
foreach归类）比硬塞进 SQL 更快，尤其当列数 > 10 或数据量 > 10 万行 - 给高频用于
CASE WHEN判断的字段建索引，哪怕只是WHERE过滤用，也能减少扫描行数从而降低CASE执行次数
用 CASE WHEN 行转列后，NULL 值怎么统一处理？
默认情况下，未命中的 CASE WHEN 返回 NULL，而聚合后的 NULL 在 SUM/AVG 中被忽略，在 MAX 中可能压掉有效值。这不是 bug，是 SQL 标准行为，但常被误认为“数据丢了”。
安全写法：
- 数值列：用
COALESCE(SUM(CASE WHEN ... THEN value END), 0)替代裸SUM - 字符串列：用
NULLIF(MAX(CASE WHEN ... THEN name END), '')防空字符串干扰，再套COALESCE(..., 'N/A') - 注意
COUNT(CASE WHEN ...)和COUNT(*)的区别——前者只计非 NULL 行，后者计所有行，别混用
最麻烦的其实是时间字段：MySQL 的 MAX(datetime) 遇到全 NULL 会返回 NULL，但有些客户端把它渲染成 0000-00-00 00:00:00，看着像数据，其实是无效值。得用 IFNULL(MAX(...), '1970-01-01') 显式兜底。
