存储过程适合做动态行转列，因为标准SQL不允许运行时决定列名，而存储过程可通过拼接字符串+执行动态SQL（如SQL Server的sp_executesql、MySQL的PREPARE/EXECUTE、PostgreSQL的EXECUTE format）实现列名来自数据表的动态生成，是应对“品类/科目等值随时新增”场景的唯一可行方案。
为什么存储过程适合做动态行转列
因为标准 SQL 不允许运行时决定列名，而存储过程能拼接字符串、执行动态 SQL，是解决「列值来自业务表、随时新增」这类问题的主流方案。它不是首选，但当 CASE WHEN 硬编码列名不可维护时，它是唯一可行路径。
MySQL 存储过程中拼接 PIVOT 式 SQL 的关键步骤
MySQL 8.0+ 虽有 PIVOT 关键字，但它不支持变量列名；仍需靠拼接字符串 + PREPARE/EXECUTE 实现动态效果。容易漏掉的环节会导致语法错误或空结果：
- 必须先查出所有要转成列的值（如科目名），用
GROUP_CONCAT拼成[Math],[English],[Science]格式 - 拼接时注意单引号、方括号、逗号的转义：字符串里写
CONCAT('SELECT user_id, ', @cols, ' FROM ...')，不能直接插变量 -
PREPARE前必须确保@sql是完整可执行语句，建议先SELECT @sql打印验证 - 执行后记得
DEALLOCATE PREPARE，否则连接内存泄漏
SQL Server 存储过程里调用 PIVOT 的坑
SQL Server 的 PIVOT 本身不支持变量，所以即使写在存储过程中，IN ([Jan], [Feb]) 这部分依然得硬编码。真要动态，还是得走字符串拼接 + sp_executesql。常见错误包括：
-
IN子句里用了单引号：IN ('Jan', 'Feb')→ 报错，必须是IN ([Jan], [Feb]) - 源子查询没起别名，或别名被忽略，导致
FOR month IN找不到字段 - 聚合函数写成
SUM却漏了NULL处理，结果列全为NULL，需配合ISNULL([Jan], 0) - 过滤条件写在
PIVOT外层：会报Incorrect syntax near the keyword 'WHERE'，必须提前塞进子查询里
PostgreSQL 存储过程（PL/pgSQL）中用 crosstab 的前提
PostgreSQL 没有原生 PIVOT，crosstab() 是最接近的替代方案，但它不是内置函数——必须先启用扩展。很多人卡在这一步就失败了：
- 首次使用前必须执行
CREATE EXTENSION tablefunc;，且需 superuser 权限 -
crosstab(text, text)第一个参数是“源查询”，第二个是“分类值查询”，二者字段数、类型必须严格匹配 - 源查询必须按分组键 + 类别键 + 值键三列顺序返回，多一列或少一列都报错
more or fewer columns than expected - 类别值查询（如
SELECT DISTINCT subject FROM scores ORDER BY subject）结果不能为空，否则整个函数返回空集
真正难的不是写出第一版动态行转列，而是让生成的列名和数据类型对齐、NULL 值可控、执行计划不退化——这些细节不会报错，但会让下游应用拿到脏数据或慢查询。
