行转列需用 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 里看得见。
