用GROUP BY配合CASE WHEN条件聚合替代PIVOT更可靠，因多数数据库不原生支持PIVOT；需为每个目标列写一个SUM/COUNT/MAX(CASE WHEN...)表达式，配合GROUP BY，且ELSE 0避免结果为NULL。
用 GROUP BY 配合条件聚合替代 PIVOT 更可靠
多数数据库（如 MySQL、PostgreSQL、SQLite）不原生支持 PIVOT，硬写会报错或语法不识别。实际中更通用的做法是用 CASE WHEN + 聚合函数手动“拼列”。核心逻辑是：对每个目标列值做一次条件判断，再用 SUM/COUNT/MAX 收集对应行数据。
比如统计各地区每季度销售额，原始表 sales 含字段 region、quarter、amount：
SELECT region, SUM(CASE WHEN quarter = 'Q1' THEN amount ELSE 0 END) AS q1_sales, SUM(CASE WHEN quarter = 'Q2' THEN amount ELSE 0 END) AS q2_sales, SUM(CASE WHEN quarter = 'Q3' THEN amount ELSE 0 END) AS q3_sales, SUM(CASE WHEN quarter = 'Q4' THEN amount ELSE 0 END) AS q4_sales FROM sales GROUP BY region;
-
ELSE 0很关键——不用NULL，避免SUM结果变NULL - 若字段本身可能为
NULL，需先用COALESCE(amount, 0)处理 - MySQL 8.0+ 和 SQL Server 支持
PIVOT，但语法不兼容，跨库迁移时仍建议用条件聚合
字符串类字段用 MAX 或 STRING_AGG 要分场景
当要转的不是数值而是文本（如产品名、状态），不能直接套 SUM。此时选聚合函数要看业务语义：
- 如果每组只有一条匹配记录（如“每个用户最新登录城市”），用
MAX或MIN安全且高效 - 如果可能多条（如“每个部门所有员工姓名”），PostgreSQL 用
STRING_AGG(name, ', ')，SQL Server 用STRING_AGG(name, ', ')（2017+），MySQL 用GROUP_CONCAT(name SEPARATOR ', ') - MySQL 的
GROUP_CONCAT默认长度限制 1024，超长会被截断，需提前设SET SESSION group_concat_max_len = 1000000
动态列数必须靠应用层拼 SQL，数据库做不到
真正的“动态交叉报表”（比如列名来自另一张表的枚举值）无法单靠 SQL 实现。数据库执行前必须知道有多少列、叫什么名。常见错误是试图在 SQL 里查出列名再 EXEC，这在 PostgreSQL/MySQL 中不可行，在 SQL Server 中也仅限存储过程且风险高。
正确路径是：
- 先查出所有需要的列值（如
SELECT DISTINCT category FROM products） - 在 Python/Java/Node.js 等应用代码里生成带
CASE WHEN的完整 SQL 字符串 - 再执行该 SQL。绕不开，也没必要绕——这是职责分离的正常设计
强行在数据库内搞动态拼接，会导致可读性差、调试困难、SQL 注入风险上升。
性能陷阱：别在大表上无索引跑 GROUP BY + 多重 CASE
条件聚合本身不慢，但若 GROUP BY 字段没索引，或 CASE 判断字段未参与查询条件，数据库可能全表扫描。例如：
SELECT user_id, COUNT(CASE WHEN action = 'login' THEN 1 END) AS login_cnt FROM event_log GROUP BY user_id;
- 若
event_log有千万行，而user_id和action都没索引，这条语句会极慢 - 优化方式：建联合索引
INDEX idx_user_action (user_id, action)，让GROUP BY和CASE都能走索引 - 某些场景下，用子查询先过滤再聚合（如加
WHERE action IN ('login', 'logout')）比在CASE里判空更高效
列转行本质是聚合操作，性能瓶颈从来不在“转”这个动作，而在底层数据访问路径是否合理。
