行转列需用CASE WHEN配合聚合函数（如MAX）与GROUP BY，而非仅靠JOIN；LEFT JOIN确保学生不丢失，CROSS JOIN维度表可补全科目；MySQL无原生PIVOT，动态列需存储过程实现。
JOIN之后怎么把行转成列（比如把“科目”变成字段）
直接用 JOIN 只能拼表，不能转结构；真正实现“透视”靠的是 CASE WHEN 配合聚合函数。本质不是 JOIN 的能力，而是用 GROUP BY 把原始多行数据压成一行，再靠 CASE 拆出不同列。
常见错误是写完 LEFT JOIN 就停了，结果发现科目还是分散在多行里，没达到“每个学生一行、各科成绩并列”的效果。
- 必须搭配
MAX(CASE WHEN subject = '数学' THEN score END)这类写法——MAX是为了在GROUP BY下取非空值，不用SUM或COUNT（除非真要算总分/次数） - 所有
CASE表达式都要放在聚合函数里，否则会报错或结果错乱 - 如果科目名来自另一张表（比如
subjects），不能直接JOIN后CASE，得先确保主表有完整科目组合，或改用动态 SQL（那是另一层复杂度）
LEFT JOIN 和 INNER JOIN 在透视场景下差在哪
选错连接类型会让整张透视表“漏人”或“漏科”。核心区别不在连接本身，而在它如何影响 CASE 能否取到值。
比如学生表 students 和成绩表 scores 关联：用 INNER JOIN 会导致没成绩的学生直接消失；用 LEFT JOIN 才能保留学生，但要注意 CASE 分支里对应科目的 score 是 NULL，聚合后就是 NULL，符合预期。
-
LEFT JOIN students ON ...是安全起点，尤其当你要“全员覆盖”时 - 如果连的是维度表（如
subjects），反而常用CROSS JOIN先生成全组合，再LEFT JOIN成绩——否则某些科目会彻底不出现在结果列中 - 别在
ON条件里写scores.subject = '数学'，这会把其他科目过滤掉，导致CASE失效
MySQL 8.0+ 的 PIVOT 替代方案靠谱吗
MySQL 原生不支持 PIVOT 关键字，所谓“8.0+ 支持”是误传。有人把 JSON_OBJECTAGG 或窗口函数凑出类似效果，但那不是标准透视，只是曲线救国。
真实项目里，硬套 JSON_OBJECTAGG(key, value) 再解析，不如老实用 CASE + 聚合清晰稳定。而且 JSON 字段没法直接参与后续数值计算或索引优化。
-
PIVOT是 SQL Server / Oracle 的语法，在 MySQL 里写会直接报错ERROR 1064 -
GROUP_CONCAT(DISTINCT CONCAT(subject, ':', score))看似简洁，但结果是字符串，无法按列筛选或排序 - 如果真需要动态列（科目不固定），得用存储过程拼 SQL，而不是依赖某个函数自动完成
性能卡点通常藏在哪几个地方
小数据看不出问题，一上万行就慢，往往不是 JOIN 本身拖垮的，而是 CASE + 聚合让执行计划变重，尤其当没索引或 GROUP BY 字段太多时。
- 确保
JOIN条件字段（如student_id、subject）都有索引，否则LEFT JOIN会触发全表扫描 -
GROUP BY的字段越多，分组代价越高；透视时尽量只按业务主键（如student_id）分组 - 避免在
CASE里嵌套函数（如UPPER(subject)），会导致索引失效，且增加 CPU 开销
最常被忽略的是：你以为在“查成绩”，其实数据库在做一次隐式笛卡尔积再过滤——尤其当多张维度表 CROSS JOIN 后再 LEFT JOIN 事实表，行数爆炸只在 EXPLAIN 里看得见。
