动态列分组应使用CASE WHEN+SUM条件聚合，必须配合GROUP BY，显式写ELSE 0避免NULL干扰；需先确认枚举值全集，PIVOT兼容性差且不真动态，应用层pivot更灵活安全。
用 CASE WHEN + SUM 实现动态列分组
SQL 本身不支持运行时生成列名，所谓“动态列”其实是把行数据转成固定几列的汇总值。最稳妥的做法是用条件聚合：对每个目标类别写一个 CASE WHEN 分支，再套一层聚合函数。
常见错误是直接在 SELECT 里写 CASE WHEN 却忘了加 GROUP BY，导致结果错乱或报错 column must appear in the GROUP BY clause。
- 必须配合
GROUP BY使用，分组字段通常是业务主键（如user_id、order_date） - 每个“动态列”对应一个
SUM(CASE WHEN ... THEN 1 ELSE 0 END)或COUNT(CASE WHEN ... THEN 1 END) - 注意
ELSE 0要显式写出，否则NULL会干扰SUM结果
SELECT region, SUM(CASE WHEN product_type = 'A' THEN sales ELSE 0 END) AS sales_A, SUM(CASE WHEN product_type = 'B' THEN sales ELSE 0 END) AS sales_B, SUM(CASE WHEN product_type = 'C' THEN sales ELSE 0 END) AS sales_C FROM orders GROUP BY region;
避免硬编码分类值：提前确认枚举范围
如果 product_type 实际有 20 种取值，但只写 3 个 CASE 分支，漏掉的类型就完全不会出现在结果里——这不是 bug，是预期行为。很多人误以为“没写的就自动为 0”，其实只是被过滤掉了。
真实场景中，分类值往往来自配置表或上游系统，不能靠猜。
- 先查
SELECT DISTINCT product_type FROM orders确认全量值 - 若值集可能变动，建议把分类列表抽成 CTE 或临时表，再用
LEFT JOIN补齐零值 - 别依赖应用层拼 SQL 字符串，容易注入且难维护
PIVOT 不是万能解，兼容性差且不灵活
SQL Server 和 Oracle 支持 PIVOT 语法，看起来更“动态”，但它要求列名在查询编译期就确定，无法用变量或子查询填充列名。PostgreSQL、MySQL 根本不支持原生 PIVOT。
用 PIVOT 的典型错误是试图传入参数：PIVOT (SUM(sales) FOR type IN (@cols)) —— 这在任何数据库里都会报错。
-
PIVOT只适合分类值稳定、数量少、且你确定只在单一数据库运行的场景 - 它内部仍被重写为多个
CASE WHEN，性能无优势 - 跨库迁移时，
PIVOT写法必须全部重写
性能与可读性的实际取舍点
当分类数超过 10 个，手写一堆 CASE WHEN 确实难维护。但比起用应用层拼 SQL 或引入存储过程，硬写仍是上线最稳的选择。
- 每个
CASE分支增加约 5% 执行开销，100 个分支才明显拖慢，一般业务查不到这个量级 - 用视图封装常用透视逻辑，比每次重写安全
- 如果真要“动态”，优先考虑在应用层做 pivot（比如 Pandas 的
pivot_table），SQL 只负责拉平数据
最常被忽略的是 NULL 处理和分组粒度错配——比如按日分组却用小时级时间戳，导致同一日期出现多行，CASE WHEN 结果就对不上了。
