mysql中case when无法动态行转列，必须配合group by和聚合函数（如max）手动为每个科目编写分支，且新增科目需修改sql；推荐应用层聚合、物化宽表或json字段等替代方案。
MySQL里CASE WHEN不能直接做动态行转列，得配合GROUP BY
想用 CASE WHEN 把“科目-分数”这种多行数据转成“学生 | 语文 | 数学 | 英语”这种宽表？别指望写个 CASE WHEN 就自动识别所有科目名——MySQL不支持动态列名，必须先知道有哪些科目，再手动写出每个 WHEN '语文'、WHEN '数学' 分支。
常见错误是这么写：
SELECT name, CASE subject WHEN '语文' THEN score END AS chinese FROM scores;
结果每行只填一个字段，其他全是 NULL。真正要的是按 name 聚合成一行，所以必须加 GROUP BY name，再用 MAX() 或 SUM() 收拢。
-
MAX(CASE WHEN subject = '语文' THEN score END)是标准写法，因为每个学生每科最多一条记录，MAX只是安全兜底 - 如果某学生有重复科目（比如补考），又想取最新一条，得先用子查询或窗口函数预处理，
CASE WHEN本身不解决去重 - 字段别名必须明确，不能写
AS subject这种和原列同名的，否则 GROUP BY 会歧义
遇到新科目就得改SQL，没有“自动加列”这回事
假设新增了“物理”成绩，下面这个查询不会自动多出一列：
SELECT name, MAX(CASE WHEN subject = '语文' THEN score END) AS chinese, MAX(CASE WHEN subject = '数学' THEN score END) AS math FROM scores GROUP BY name;
你得手动追加一行：
MAX(CASE WHEN subject = '物理' THEN score END) AS physics
这也是为什么业务系统里很少纯靠 SQL 做动态 pivoting：前端或应用层得先查一遍 SELECT DISTINCT subject FROM scores，拼出完整 SQL 再执行。有些 ORM 或 BI 工具（如 Metabase）会帮你干这事，但原生 MySQL 不会。
- 用存储过程拼接 SQL 是可行的，但运维成本高、难调试、权限受限（需要
EXECUTE权限） -
PREPARE+EXECUTE能实现，但无法在视图或普通查询中复用，也不支持参数化传入列名列表 - 如果科目数超 50 个，手写
CASE WHEN分支容易漏、难维护，这时该考虑换存储结构（比如 JSON 字段存科目分数）或换工具链
性能瓶颈常出在GROUP BY和索引缺失上
当 scores 表有百万级数据，而你只查 10 个学生，却对全表 GROUP BY name，速度可能很慢。关键不是 CASE WHEN 本身耗资源，而是分组动作没走索引。
- 确保
(name, subject)有联合索引，顺序不能反——GROUP BY name需要前导列命中 - 如果只查部分学生，务必把
WHERE name IN (...)加在GROUP BY前面，避免扫描全表 -
CASE WHEN分支越多，SELECT 列越宽，网络传输和内存占用也线性上升，别无谓堆几十个科目字段 - 用
EXPLAIN看执行计划时，重点关注type是否为ref或range，而不是ALL
替代方案比硬刚CASE WHEN更实际
真要应对科目频繁增减的场景，硬写 CASE WHEN 是自找麻烦。几个更靠谱的选择：
- 应用层聚合：查出
name, subject, score扁平结果，在 Python/Java 里用pandas.pivot()或Map<string map integer>></string>组装，灵活且易测试 - 物化宽表：每天定时跑一个含全科目的
CASE WHEN查询，结果存到新表，查询走这张表，牺牲实时性换简单性 - JSON 字段：MySQL 5.7+ 支持
JSON_OBJECTAGG()，可生成{"语文": 85, "数学": 92}，虽不是标准列，但程序解析方便，增减科目零SQL变更 - 别用 MySQL 做这事：OLAP 场景优先考虑 ClickHouse、Doris 或 StarRocks，它们原生支持
PIVOT语法和动态列推导
最常被忽略的一点：所谓“动态”，往往只是人脑觉得它该自动变；而数据库眼里，列结构是 schema 的一部分，稳定才利于优化。先想清楚“动态”到底是谁的诉求、频次多少、能否接受缓存延迟——再决定要不要在 SQL 层死磕 CASE WHEN。
