MySQL 8.0+ 不支持原生 PIVOT 语法，所谓“PIVOT 示例”多为误传；正确做法是用 CASE WHEN 搭配 SUM/MAX 等聚合函数实现行转列，需 GROUP BY 分组，推荐显式写 ELSE NULL 或 COALESCE 处理空值。
MySQL 8.0+ 用 PIVOT？别试了，它不支持
MySQL 直到 8.0.33 都没有原生 PIVOT 语法。你搜到的所谓“PIVOT 示例”基本是误传或混淆了 SQL Server 语法。真要用行转列，得靠条件聚合——这是最稳、兼容性最好、也最容易控制汇总逻辑的方式。
典型场景：一张销售记录表 sales，字段含 region（地区）、product（品类）、amount（金额），你想按地区横向展开各品类销售额总和。
- 错误写法：
SELECT * FROM sales PIVOT(SUM(amount) FOR product IN ('A','B'))→ 报错ERROR 1064 - 正确思路：用
CASE WHEN搭配SUM()，每个品类构造一列 - 注意
NULL值处理：没发生过销售的品类会出NULL，建议用COALESCE(SUM(...), 0)转成 0
PostgreSQL 怎么写带聚合的行转列
PostgreSQL 有 crosstab() 函数，但它要求提前知道列名且依赖 tablefunc 扩展，实际项目中反而不如手动 CASE 灵活可靠。
更推荐写法：直接在 SELECT 中用条件聚合，配合 GROUP BY 完成分组汇总。
SELECT region, COALESCE(SUM(CASE WHEN product = 'A' THEN amount END), 0) AS "A_sales", COALESCE(SUM(CASE WHEN product = 'B' THEN amount END), 0) AS "B_sales", COALESCE(SUM(CASE WHEN product = 'C' THEN amount END), 0) AS "C_sales" FROM sales GROUP BY region;
- 每列对应一个固定
product值，不能动态生成新列（比如新增品类 D 就得改 SQL） - 如果品类太多，手写
CASE易错；可先用SELECT DISTINCT product FROM sales查出值，再拼 SQL -
SUM()本身会自动跳过NULL，所以CASE没匹配时返回NULL是安全的
SQL Server 的 PIVOT 要小心聚合逻辑陷阱
SQL Server 支持 PIVOT，但它强制要求指定一个**聚合函数**，而且这个聚合是作用在「每一组目标列值」上的——不是对整行，而是对每个 FOR 列值下的所有源行。
常见翻车点：想转列又想保留明细，结果发现 PIVOT 强制压缩，没法绕过。
SELECT region, [A], [B], [C] FROM ( SELECT region, product, amount FROM sales ) AS src PIVOT ( SUM(amount) FOR product IN ([A], [B], [C]) ) AS pvt;
- 必须写
SUM(amount)或其他聚合函数，不能写amount单值 - 如果同一
region下有多个product = 'A'记录，PIVOT会自动加总——这既是特性也是限制 - 列名
[A]中的方括号不能省，否则含空格或关键字会报错Incorrect syntax near 'A'
动态行转列：为什么多数情况该交给应用层做
真正麻烦的是“品类不固定”，比如每天新增一个产品，SQL 得实时生成列名。数据库层面硬搞动态 SQL（如 MySQL 的 PREPARE + EXECUTE）极易出错、难调试、还可能被权限拦住。
更务实的做法：SQL 只查出规范的长格式（region, product, amount），让 Python/Java/Node.js 拿到结果后用 pandas.pivot_table() 或 Map<string map number>></string> 组装宽表。
- 数据库只负责可靠取数，逻辑交给语言层——解耦清晰，改需求不碰 SQL
- 避免存储过程里拼接字符串导致 SQL 注入（尤其当
product来自用户输入） - 如果非要在 DB 层做，PostgreSQL 可用
json_object_agg()先聚合成 JSON，再解析，但性能和可读性都打折扣
行转列本身不难，难的是想清楚“列是否固定”“聚合粒度在哪一层”“谁该为扩展性负责”。硬在 SQL 里塞动态逻辑，往往只是把问题从应用日志挪到了慢查询日志里。
