必须用group by配合case when才能行转列，因为行转列本质是按某字段分组后将组内不同值映射到多列并聚合；单靠case when仅生成临时列，不加group by无法压缩多行成一行，否则结果重复、错位或报错error 1140。
为什么必须用 GROUP BY 配合 CASE WHEN 才能行转列
因为行转列本质是「按某字段分组 → 把同一组内不同值映射到不同列 → 取每个列的代表值」。单靠 CASE WHEN 只能生成临时列，但每行仍是一条原始记录；不加 GROUP BY 就无法压缩多行成一行，结果会重复、错位、漏聚合。
常见错误现象：CASE WHEN 写对了，但没写 GROUP BY，导致每个学生每门课占一行，而不是一个学生一行三列；或者用了 MAX() 却没分组，MySQL 8.0+ 会报错 ERROR 1140: In aggregated query without GROUP BY。
-
GROUP BY的字段必须是你要“保留为行标识”的字段（如name、product_id） - 所有非分组字段都必须被聚合函数包裹，否则语法不通过（MySQL 5.7 严格模式下尤其明显）
- 如果原始数据里存在重复组合（如张三有两条“语文”记录），
MAX()取最大值，SUM()求和，AVG()算均值——选哪个取决于业务语义
CASE WHEN 中该用 0 还是 NULL？
区别直接影响聚合结果：MAX() 遇到全 NULL 返回 NULL，遇到含 0 则可能返回 0（比如某学生没考数学，你填了 0，结果就显示 0 分而非空）。
使用场景建议：
- 用
NULL更安全：写成CASE WHEN subject='数学' THEN score END（不写ELSE），这样没匹配时自动为NULL，MAX()和SUM()都会忽略它 - 用
0仅当“缺值即为零”有明确业务含义（如统计签到次数，未打卡=0次） - 避免混用：不要有的列用
0、有的用NULL，会导致结果列类型不一致或隐式转换问题
性能瓶颈常卡在哪儿
行转列本身不复杂，但数据量大时容易慢，关键瓶颈不在 CASE WHEN，而在三处：
-
GROUP BY字段无索引：比如按name分组但没建索引，MySQL 被迫全表扫描+临时文件排序 - 源表数据倾斜：某个
name对应几百门课，而其他只有一两门，GROUP_CONCAT()替代方案会因长度限制截断（默认group_concat_max_len = 1024） - 列数爆炸：硬编码 20 个
CASE WHEN字段，SQL 解析和执行计划生成变慢，且难以维护；动态生成 SQL 需程序层配合，不能纯靠 SQL 完成
简单验证方式：EXPLAIN 看是否出现 Using temporary; Using filesort，如果有，优先加索引或缩小数据范围（加 WHERE 条件）。
MySQL 8.0+ 的 PIVOT 是真语法还是营销话术
不是真语法。MySQL 官方文档至今（2026 年 5 月）**没有 PIVOT 关键字**。网上所谓 “MySQL 8.0 支持 PIVOT” 实为误传，可能混淆了 MariaDB 10.5+ 的实验性 PIVOT，或把窗口函数、CTE 等新特性张冠李戴。
所以别信教程里这种写法：SELECT * FROM t PIVOT (SUM(sales) FOR month IN ('Jan','Feb')) —— 在 MySQL 里直接报错 ERROR 1064。
真正可用的只有两种路径：
- 手写
CASE WHEN + 聚合 + GROUP BY（兼容所有版本，可控性强） - 用
GROUP_CONCAT()+ 字符串切分（适合列数固定、值较短、允许字符串中间处理的场景）
动态列名（比如科目不固定）必须由应用层拼 SQL 或用存储过程组装，MySQL 原生不支持元数据驱动的列生成。
