手动聚合是最快上手的行转列方式，适用于无PIVOT功能的数据库；核心是用CASE WHEN提取值并套MAX()/SUM()消除NULL，漏掉外层聚合函数会导致结果未合并。
用 CASE WHEN 手动聚合是最快上手的方式
没有 PIVOT 的数据库（比如 MySQL 8.0 之前、SQLite、部分 PostgreSQL 场景）必须靠条件聚合。核心思路是：对每个目标列值，用 CASE WHEN 提取对应字段，再套一层 MAX() 或 SUM() 消除空值干扰。
常见错误是漏掉外层聚合函数，导致结果按原行数展开，而非合并成一行：
SELECT user_id, MAX(CASE WHEN month = 'Jan' THEN sales END) AS jan_sales, MAX(CASE WHEN month = 'Feb' THEN sales END) AS feb_sales FROM sales_data GROUP BY user_id;
-
MAX()在这里不是为了取最大值，而是作为“非空兜底”——每组中只有一个非 NULL 值，MAX()会返回它；用COALESCE(MAX(...), 0)可统一补零 - 若原始数据中同一
user_id + month有多条记录，需先明确聚合逻辑（如求和），此时应把SUM(CASE ...)放在内层 - 所有
CASE WHEN分支必须覆盖全部可能值，或加ELSE NULL，否则意外值会被静默丢弃
PostgreSQL 和 SQL Server 可直接用 PIVOT，但语法差异大
SQL Server 的 PIVOT 是标准语法，但要求明确列出所有列名，不支持动态列；PostgreSQL 则需借助 crosstab() 函数，且依赖 tablefunc 扩展。
SQL Server 示例（注意括号嵌套层级和别名位置）：
SELECT * FROM ( SELECT user_id, month, sales FROM sales_data ) AS src PIVOT (SUM(sales) FOR month IN ([Jan], [Feb], [Mar])) AS pvt;
- 方括号
[Jan]是必需的，字符串字面量不行；若列名含空格或特殊字符，必须用方括号包裹 -
PIVOT后不能接WHERE，过滤需放在子查询里，否则报错Incorrect syntax near the keyword 'WHERE' - PostgreSQL 中未启用
tablefunc时调用crosstab()会提示function crosstab(unknown) does not exist，需先执行CREATE EXTENSION tablefunc;
MySQL 8.0+ 可用 JSON_OBJECTAGG 曲线救国
当列名不确定、需要动态生成时，CASE WHEN 硬编码就不可行。MySQL 8.0 引入的 JSON_OBJECTAGG 能把键值对聚合成 JSON，再配合应用层解析，比拼接 SQL 更安全。
SELECT user_id, JSON_OBJECTAGG(month, sales) AS monthly_sales FROM sales_data GROUP BY user_id;
- 结果是类似
{"Jan": 1200, "Feb": 950}的 JSON 字符串，不是宽表结构，适合前端或中间层消费 - 若需转回字段，仍得靠应用代码或存储过程拼接 SQL —— 这里没有银弹，动态列本质就是元数据操作
- 注意
JSON_OBJECTAGG会自动跳过NULL键或值，如果业务允许缺失月度数据，这反而是优点
性能和可维护性陷阱：别在大表上无索引跑行转列
行转列本质是 GROUP BY + 多重扫描，当源表超百万行且没合适索引时，响应可能从毫秒级变成分钟级。
- 确保
GROUP BY字段（如user_id）和CASE WHEN的判别字段（如month）上有联合索引，例如INDEX idx_user_month (user_id, month) - 避免在
CASE WHEN中调用函数，如CASE WHEN YEAR(order_date) = 2023—— 这会让索引失效，应提前算好年份字段再参与判断 - 如果只是临时看数，优先考虑应用层分组（如 Python pandas 的
pivot_table），数据库只负责吐明细，更可控
动态列需求越强，越要接受“数据库只做稳定结构”的事实；强行在 SQL 层做弹性列，最后往往卡在权限、字符集或 JSON 解析兼容性上。
