MySQL不支持PIVOT语法，必须用CASE WHEN+聚合函数模拟；8.0及之前版本均不识别PIVOT关键字，强行使用会报ERROR 1064语法错误，所谓“8.0支持”系误传。
MySQL 本身不支持 PIVOT 语法，必须用 CASE WHEN + 聚合函数手动模拟，这是最稳定、兼容性最好的方案。
为什么不能直接用 PIVOT？
MySQL 8.0 之前完全不识别 PIVOT 关键字；8.0 及之后版本仍不支持标准 SQL 的 PIVOT 操作（PostgreSQL/SQL Server 支持）。强行写会报错：ERROR 1064 (42000): You have an error in your SQL syntax。
常见错误场景包括：从其他数据库导出带 PIVOT 的 SQL 直接在 MySQL 执行、或误信某些博客说“MySQL 8.0 已支持”。
用 CASE WHEN + MAX() 或 SUM() 实现静态行转列
适用于列名固定、可预知的统计报表（如按季度、按产品类型、按地区汇总）。
- 每个目标列写一个
CASE WHEN分支，配合聚合函数包裹，否则会多行输出 - 用
MAX()适合取非空值（比如姓名、状态），用SUM()适合求和（比如销量、金额） - 必须搭配
GROUP BY，且GROUP BY字段是行转列后要保留的维度（如user_id、year） - 注意
ELSE NULL可省略，但显式写出更清晰；NULL 值在MAX()中会被自动忽略
SELECT user_id, MAX(CASE WHEN month = 'Jan' THEN amount END) AS Jan, MAX(CASE WHEN month = 'Feb' THEN amount END) AS Feb, MAX(CASE WHEN month = 'Mar' THEN amount END) AS Mar FROM sales GROUP BY user_id;
动态行转列只能靠应用层拼接 SQL
当列名来自数据（如动态生成的品类、标签、年份），MySQL 无法原生生成列结构——没有 EXECUTE IMMEDIATE 或存储过程返回动态列的能力。
- 存储过程可以拼
@sql并用PREPARE/EXECUTE，但调用方仍需知道列名才能解析结果集 - 真正实用的方式是：应用代码（Python/Java/PHP）先查出所有要转的列值（如
SELECT DISTINCT category FROM products），再拼出含多个CASE WHEN的 SQL 发给 MySQL - 不要试图在视图或普通查询里“自动适配新列”，那只会让逻辑不可维护、性能不可控
性能与可读性权衡要点
超过 10–15 个 CASE WHEN 分支时，SQL 会明显变长、难调试，但执行效率通常优于多次 JOIN 或子查询。
- 确保被
CASE WHEN判断的字段（如month、status）上有索引，否则全表扫描代价高 - 避免在
CASE WHEN内写复杂表达式或子查询，MySQL 优化器难以准确估算成本 - 如果报表需要频繁变更列结构，建议把行转列逻辑移到应用层或用 OLAP 引擎（如 ClickHouse）处理，别硬扛在 MySQL 上
真正的难点不在怎么写第一行 CASE WHEN，而在于后续加新列时要不要改 SQL、谁来维护这个映射关系、以及 NULL 值在前端展示时是否被正确处理——这些往往比语法本身更消耗时间。
