MySQL中CASE WHEN行转列必须配合GROUP BY和聚合函数，仅用CASE WHEN只能生成临时列，无法实现宽表结构；动态列名需应用层拼SQL或存储过程，非CASE WHEN能力范围。
MySQL 中用 CASE WHEN 做静态行转列，必须配合 GROUP BY 和聚合函数
直接写 CASE WHEN 不会自动“转列”，它只是生成一列临时计算值；真正实现“把不同类别的值摊到多列”，得靠 SUM()、COUNT() 或 MAX() 把每组内各条件的结果聚合成单个标量。否则你只会得到一堆重复行，而不是宽表结构。
典型场景：统计每个部门中「男」「女」人数，想输出为 dept_name、male_count、female_count 三列。
-
CASE WHEN gender = 'M' THEN 1 ELSE 0 END本身是表达式，不能单独存在，必须套进SUM()或COUNT() - 漏掉
GROUP BY dept_name会导致全表只聚合出一行，无法按部门区分 - 用
MAX()替代SUM()仅适用于“每组至多一个匹配”的情况（如取最新状态），别乱套用
SELECT dept_name, SUM(CASE WHEN gender = 'M' THEN 1 ELSE 0 END) AS male_count, SUM(CASE WHEN gender = 'F' THEN 1 ELSE 0 END) AS female_count FROM employees GROUP BY dept_name;
动态列名无法用纯 SQL 实现，CASE WHEN 只能处理预知的枚举值
如果类别（比如产品线、地区、月份）是运行时才确定的，MySQL 没有内置机制自动生成列名。所谓“动态行列转换”，本质是应用层拼 SQL，或用存储过程拼接 SELECT 字句——不是 CASE WHEN 的能力范围。
常见误解：以为加个变量就能让列名变活。但列名在 SQL 解析阶段就必须固定，PREPARE + EXECUTE 可以绕过，但代价是失去可读性、难调试、无法被 ORM 安全识别。
- 硬编码
CASE WHEN product = 'A' THEN sales END是安全且高效的，只要你知道所有product取值 - 试图用
@cols变量生成列列表，再塞进SELECT，属于高风险操作：SQL 注入隐患大，EXPLAIN 看不到真实执行计划 - 若源数据类别过多（如 200+ 个省份），手工写 200 个
CASE段不现实，这时该考虑换工具（Python pandas pivot、BI 工具、或导出后处理）
性能陷阱：CASE WHEN 嵌套过深或条件太多，会拖慢 GROUP BY 排序与聚合
MySQL 在执行含多个 CASE WHEN 的聚合时，对每一行都要逐条判断所有分支。当分支数超过 5–7 个，且数据量大（千万级），CPU 成为瓶颈比 I/O 更明显。
- 避免写成
CASE WHEN a=1 THEN x WHEN a=2 THEN y ... WHEN a=100 THEN z END，改用查找表JOIN或提前在应用层归类 - 条件中不要调用函数（如
CASE WHEN YEAR(create_time) = 2023 THEN 1），这会让索引失效；应改用范围查询预处理 - 确认
GROUP BY字段有索引——没有索引的GROUP BY会强制临时表 + filesort，此时再多优化CASE也没用
替代方案选型：什么情况下不该硬扛 CASE WHEN
当报表维度交叉频繁、列方向需灵活展开、或需要累计/同比/占比等衍生指标时，CASE WHEN 就不是最佳解。它适合“固定维度 + 简单计数/求和”，其余场景容易陷入维护泥潭。
- 需要透视多个字段组合（如按
region×product_type×quarter展开）→ 用GROUP BY多字段 + 应用层 pivot，别堆CASE - 要支持用户自定义分组或筛选 → 后端生成 SQL 风险高，建议用 ClickHouse / DuckDB 做中间计算，或前端用 AG-Grid 动态 pivot
- 已有 ETL 流程 → 在调度任务里用 Spark 或 dbt 做宽表预计算，查表比实时
CASE WHEN快一个数量级
最常被忽略的一点：CASE WHEN 行转列结果不可索引。一旦业务要求按“女性人数 > 100”快速筛选，你就只能全表扫描——这种需求从一开始就不该放在 MySQL 查询层解决。
