MySQL、PostgreSQL等主流数据库不支持PIVOT语法，因SQL标准无此关键字，仅SQL Server和Oracle原生支持；直接使用会报语法错误，必须用CASE WHEN配合SUM/MAX等聚合函数手动实现行转列，且每列须显式写出并带ELSE子句。
MySQL、PostgreSQL 等主流数据库不支持 PIVOT 语法，直接写会报错（如 syntax error at or near "PIVOT"）；必须用 CASE WHEN + 聚合函数组合实现，且每列都要显式写出、不能漏 ELSE。
为什么不能直接用 PIVOT？
SQL 标准里没有 PIVOT 关键字，只有 SQL Server 和 Oracle 11g+ 原生支持。你在 MySQL 或 PostgreSQL 里执行 SELECT ... PIVOT(...)，一定会遇到语法错误。这不是版本问题，是引擎根本不识别这个关键字。
常见错误现象包括：
-
ERROR: syntax error at or near "PIVOT"（PostgreSQL） -
ERROR 1064 (42000): You have an error in your SQL syntax（MySQL）
别查“如何开启 MySQL 的 PIVOT”，它压根不存在。你要做的是用等效逻辑手写出来。
CASE WHEN + SUM/MAX 怎么写才不出错？
核心不是“能不能转”，而是“转完结果是否可读、可维护、不崩”。关键点有三个：
- 每个
CASE WHEN必须配一个聚合函数：即使源数据中每个分组下part_type是唯一的，也得写MAX(CASE WHEN part_type = 'A' THEN part_id END)，不能只写CASE - 必须加
ELSE：比如MAX(CASE WHEN part_type = 'A' THEN part_id ELSE 0 END)，否则整列可能为NULL（尤其当某组完全没匹配上时） -
GROUP BY粒度要和输出行逻辑一致：例如按product_id展开各part_type，那GROUP BY product_id就够了；若再加created_at，结果行数可能翻几十倍
示例（把 part_type A/B/C 拆成三列）：
SELECT product_id, MAX(CASE WHEN part_type = 'A' THEN part_id ELSE 0 END) AS part_A_id, MAX(CASE WHEN part_type = 'B' THEN part_id ELSE 0 END) AS part_B_id, MAX(CASE WHEN part_type = 'C' THEN part_id ELSE 0 END) AS part_C_id FROM parts GROUP BY product_id;
数值型 vs 字符型字段，该用 SUM 还是 MAX？
选错聚合函数会导致结果错乱或全 NULL：
- 数值类指标（销售额、数量）：优先用
SUM，语义明确；如果确认每组最多一条记录，MAX或MIN也行 - ID、编码、状态码等标识类字段：必须用
MAX或MIN；SUM会把字符串隐式转 0，或者直接报错（如 PostgreSQL） - 字符串内容（如产品名、备注）：只能用
MAX或MIN，且需确保排序规则合理（MySQL 默认按字典序，中文可能乱序）
特别注意：AVG 和 COUNT 在行转列中极少使用——它们不返回原始值，而是统计量，容易偏离业务预期。
列名不确定时，怎么动态生成？
标准 SQL 不允许运行时决定列名，所谓“动态 PIVOT”本质是拼 SQL 字符串。MySQL 可用 GROUP_CONCAT + PREPARE 实现，但有硬限制：
-
GROUP_CONCAT默认最大长度是 1024，必须提前设大：SET SESSION group_concat_max_len = 1000000; - 拼出的 SQL 字符串不能含换行或多余空格，否则
PREPARE失败 - IN 子句里的列名必须用反引号包裹，如
`Math`，不能写成Math（否则字段含空格或特殊字符时崩） - 无法在普通查询中嵌套执行，必须拆成两步：先查出所有唯一值 → 拼 SQL →
PREPARE→EXECUTE
真正上线项目中，90% 的动态场景更适合交给应用层处理（Python/Java 拼 SQL），而不是塞进存储过程——可读性差、调试难、权限管控麻烦。
最容易被忽略的一点：CASE WHEN 行转列不是“加功能”，而是“改数据粒度”。一旦 GROUP BY 错了，结果既不对也不快；而聚合函数选错，可能表面看着对，实际某类数据永远丢值。动手前先确认分组键是否真能唯一确定一行输出。
