PIVOT是SQL Server/Oracle实现静态行列转换的直观方案，需对值字段聚合、行字段分组，IN子句须枚举列名；通用场景用CASE WHEN+聚合替代，注意ELSE处理、GROUP BY及类型对齐。
用 PIVOT 实现静态行列转换（SQL Server / Oracle）
SQL 标准本身不直接支持行列转换，但主流数据库提供了语法糖。SQL Server 的 PIVOT 是最直观的方案，适合列名已知、数量固定的报表场景。
常见错误是把聚合字段和分组字段搞混：必须对要“摊开”的数值列做聚合（如 SUM、COUNT），而行维度字段（如 product）不能参与聚合，需出现在外部 SELECT 或 GROUP BY 中。
- 写法必须嵌套：先查出基础数据（含行字段、列字段、值字段），再用
PIVOT包裹 -
FOR后跟的是要转成列的字段名（如region），IN里必须写死枚举值（如[North], [South], [East]），不能用子查询或变量 - Oracle 11g+ 支持类似语法，但关键字是
PIVOT（同 SQL Server），而旧版得靠CASE WHEN模拟
示例（SQL Server）：
SELECT product, [North], [South], [East] FROM ( SELECT product, region, sales FROM sales_data ) AS src PIVOT ( SUM(sales) FOR region IN ([North], [South], [East]) ) AS pvt;
用 CASE WHEN + 聚合实现动态兼容写法（MySQL / PostgreSQL / 通用）
当数据库不支持 PIVOT（如 MySQL 8.0 以前），或列名不确定（比如按月份展示，但月份范围随数据变化），就得用 CASE WHEN 手动展开。它本质是“为每个目标列写一个条件聚合”，兼容性最好。
容易踩的坑是漏掉 ELSE 0 或 ELSE NULL：没有匹配的行会导致该列结果为 NULL，影响求和或前端渲染；另外，所有 CASE 必须套在同一个聚合函数里，不能每个列单独 GROUP BY。
- 每个目标列对应一个
SUM(CASE WHEN region = 'North' THEN sales ELSE 0 END) - 行维度字段（如
product）必须出现在GROUP BY中 - 如果列名来自另一张表（如动态月份），需先用字符串拼接生成 SQL，再执行 —— 这属于应用层逻辑，SQL 视图本身做不到真动态
示例（通用写法）：
SELECT product, SUM(CASE WHEN region = 'North' THEN sales ELSE 0 END) AS North, SUM(CASE WHEN region = 'South' THEN sales ELSE 0 END) AS South, SUM(CASE WHEN region = 'East' THEN sales ELSE 0 END) AS East FROM sales_data GROUP BY product;
创建视图时要注意 NULL 和数据类型对齐
视图只是保存查询语句，不存数据，所以行列转换逻辑会每次执行。但正因如此，NULL 处理和类型隐式转换会在运行时暴露问题 —— 尤其当某列全无匹配数据时，SUM 返回 NULL，而其他列是数字，可能导致前端报错或图表渲染异常。
- 统一用
COALESCE(SUM(...), 0)替代裸SUM，避免空值穿透 - 所有
CASE WHEN分支的返回类型必须一致，否则数据库可能报inconsistent datatypes；例如混合了INT和VARCHAR，需显式CAST - 视图中别名不能重复，也不能用保留字（如
order、user），否则后续SELECT *会失败
为什么别在视图里做超宽表转换（>20 列）
行列转换后列数暴增，视图定义会变得极难维护。更关键的是，数据库优化器对宽表 SELECT 的代价估算容易失真，尤其配合 WHERE 过滤时，可能跳过本该用上的索引。
真正复杂的报表建议分两层：视图只做轻量级预聚合（如按日/产品/地区汇总），把“转列”逻辑交给 BI 工具或应用代码。SQL 视图的核心价值是封装可复用的数据口径，不是替代透视引擎。
如果你发现视图里写了 15 个 CASE WHEN，还带 UNION ALL 拼不同年份 —— 那已经不是视图，是硬编码报表，改起来疼，查起来慢。
