CASE WHEN + GROUP BY 是最稳妥的行转列方式，因MySQL原生不支持PIVOT，该方案逻辑清晰、兼容5.7+所有版本、可索引优化，且能精确控制列名、值类型与空值行为。
SUM(CASE WHEN ...) 是最稳妥、兼容性最好的行转列写法，MySQL 5.7 及以上都支持，不需要升级或额外函数。
用 CASE WHEN + 聚合函数做静态行转列
这是实际项目中最常用、最可控的方式。核心是：对每个目标列值写一个 CASE WHEN 分支，再用 SUM、MAX 或 AVG 聚合（选哪个取决于业务逻辑）。
-
SUM最常用，适合数值型字段且每组最多一条匹配记录；若出现重复 subject，会累加——这可能是 bug 也可能是需求 -
MAX更安全，能自动去重取最大值，适合非数值字段或不确定是否唯一时 - 别用
COUNT直接套CASE，它统计的是“满足条件的行数”，不是你想填进去的 score 值 - 必须配
GROUP BY，否则聚合结果会坍缩成一行 - 示例：
SELECT userid,<br> MAX(CASE WHEN subject = '语文' THEN score END) AS '语文',<br> MAX(CASE WHEN subject = '数学' THEN score END) AS '数学',<br> MAX(CASE WHEN subject = '英语' THEN score END) AS '英语'<br>FROM tb_score<br>GROUP BY userid;
IF() 替代 CASE WHEN 的写法差异
IF(subject = '语文', score, NULL) 和 CASE WHEN subject = '语文' THEN score END 功能等价，但有细微差别：
-
IF()是 MySQL 特有函数，CASE是 SQL 标准，可移植性更好 - 两者在性能上几乎无差别，但
IF()写法更紧凑，适合简单二选一场景 - 注意：
IF()第三个参数不能省略，写成IF(..., score)会报错；必须显式写NULL或0 - 聚合函数里用
NULL比用0更合理——避免把缺考（本该为 NULL）误算成 0 分
MySQL 8.0+ 的 PIVOT 并不原生存在
网上很多文章说 “MySQL 8.0 支持 PIVOT”，这是误导。官方文档从未引入 PIVOT 关键字。所谓“8.0+ PIVOT” 实际是用 JSON_OBJECTAGG + JSON_EXTRACT 模拟出来的，写法绕、可读性差、调试困难。
- 例如：
JSON_UNQUOTE(JSON_EXTRACT(pivot_data, '$."语文"'))这种嵌套极易出错 - 它依赖 JSON 函数，要求字段值能合法转成 JSON 字符串（比如不能含未转义的双引号）
- 性能比
CASE差，因为要序列化/反序列化 - 除非已有现成 JSON 架构且强依赖动态列，否则没必要碰这套方案
动态行转列为什么难落地
当 subject 值不固定（比如运营后台随时新增科目），硬编码 CASE 不现实。但“动态生成 SQL” 不等于“自动执行”，关键点在于：
- 必须用存储过程或应用层拼接 SQL，MySQL 本身不支持变量列名
- 拼出的 SQL 需预编译或用
PREPARE/EXECUTE，增加了复杂度和安全风险（SQL 注入） - 每次科目变更都要触发元数据查询 + 重生成语句，缓存难做，响应延迟不可控
- 真实业务中，90% 的“动态”需求其实只需前端适配列名，后端仍走静态 SQL + 字段映射
真正容易被忽略的是：行转列本质是展示层逻辑，不该压到数据库里做。如果列太多、变化太勤，优先考虑把宽表逻辑移到应用层或 OLAP 引擎（如 ClickHouse）处理。
