GROUP BY 本身不能直接做动态透视，必须配合 CASE WHEN + 聚合函数模拟，再由应用层或存储过程拼接 SQL；PIVOT 非 ANSI 标准，PostgreSQL 无原生支持，MySQL 8.0+ 虽有但不支持动态列，因此所谓“动态透视”本质是静态列枚举加条件聚合，真动态需客户端查值、拼 SQL 并执行。
GROUP BY 本身不能直接做动态透视，必须配合条件聚合
SQL 标准语法里没有 PIVOT 的通用实现（PostgreSQL 没原生 PIVOT，MySQL 8.0+ 有但不支持动态列），所以所谓“动态透视”，本质是用 CASE WHEN + 聚合函数模拟，再靠应用层或存储过程拼接 SQL。硬写死列名的 GROUP BY 只能算静态分组汇总，不是透视。
常见错误是试图在 SELECT 里直接写 GROUP BY category, dynamic_column —— 这根本不会生成宽表结构，只会按两列联合分组，结果行数反而可能更多。
- 真正需要的是：同一
GROUP BY键下，把不同值的行“折叠”成多个列 - 比如按
product_id分组，把region = 'US'的销量放进us_sales列，region = 'CN'的放进cn_sales列 - 列名必须提前知道，否则 SQL 解析器无法校验字段合法性
用 MAX(CASE WHEN ...) 实现静态透视（最常用）
这是跨数据库兼容性最好的写法，适用于已知有限枚举值的场景（如固定几个地区、状态、年份）。核心是每个目标列对应一个 CASE WHEN 分支，外层套聚合函数避免报错。
SELECT product_id, MAX(CASE WHEN region = 'US' THEN sales END) AS us_sales, MAX(CASE WHEN region = 'CN' THEN sales END) AS cn_sales, MAX(CASE WHEN region = 'EU' THEN sales END) AS eu_sales FROM sales_table GROUP BY product_id;
注意点：
- 用
MAX或SUM而非COUNT：因为每组每行只匹配一个CASE分支，其余为NULL，MAX取非空值；若需累加（如多笔订单），改用SUM - 别漏
ELSE NULL（虽默认就是NULL，但显式写出更安全） - 如果
region有新值（比如新增'JP'），必须手动加一列，SQL 才会体现
PostgreSQL 中用 crosstab() 做半动态透视（需额外扩展）
PostgreSQL 通过 tablefunc 扩展提供 crosstab() 函数，能减少手写 CASE 的重复劳动，但依然不是真动态——它要求你预先声明返回的列定义，且列数、类型必须和查询结果严格匹配。
典型用法：
SELECT * FROM crosstab( 'SELECT product_id, region, sales FROM sales_table ORDER BY 1,2', 'SELECT DISTINCT region FROM sales_table ORDER BY 1' ) AS ct(product_id TEXT, us_sales NUMERIC, cn_sales NUMERIC, eu_sales NUMERIC);
坑点：
- 第二条 SQL 必须返回**有序、确定数量**的值，否则
crosstab()报错：return and input tuples not same length -
AS ct(...)里的列定义必须和实际数据对得上；加了新region就得同步改这里，否则查询失败 - 首次使用前要运行
CREATE EXTENSION tablefunc;，很多生产环境默认没开
真动态列只能靠客户端拼 SQL（绕不开的现实）
如果列名完全不可预知（比如用户上传 CSV 后按任意字段透视），数据库层无解。必须由应用代码（Python/Java/Node.js）先查出所有唯一值，构造 CASE 表达式字符串，再执行动态 SQL。
例如 Python + psycopg2：
regions = [r[0] for r in cur.execute("SELECT DISTINCT region FROM sales_table ORDER BY region").fetchall()]
case_sql = ", ".join([f"MAX(CASE WHEN region = '{r}' THEN sales END) AS {r.lower()}_sales" for r in regions])
full_sql = f"SELECT product_id, {case_sql} FROM sales_table GROUP BY product_id"关键约束：
- 必须严格过滤
regions中的单引号、反斜杠等，否则 SQL 注入（用参数化不行，因为列名不能参数化） - 列数过多时（比如几百个地区），生成的 SQL 可能超 PostgreSQL 的
max_identifier_length或内存限制 - 每次列变动都触发 SQL 重编译，缓存失效，高频场景性能不如预定义视图
动态性的代价是失去 SQL 静态分析能力——语法检查、执行计划预估、权限校验全推到运行时，这也是为什么多数 BI 工具（如 Metabase、Superset）选择在前端做 pivot，而非强求数据库输出宽表。
