直接用 GROUP BY 无法实现行转列，因其仅聚合数据而不改变列结构；行转列本质是透视操作，需用条件聚合（CASE WHEN + SUM）等方案实现。
为什么直接用 GROUP BY 无法实现行转列
因为 GROUP BY 只负责聚合，不改变结果集的列结构。你想把「每个用户每种订单状态出现次数」变成「一行为一个用户，列为待支付/已发货/已完成」，这本质是透视（pivot），不是分组本身能解决的。
常见错误是试图用嵌套子查询拼字段，结果要么报错，要么性能爆炸——尤其数据量稍大时，GROUP BY + 多个关联子查询会反复扫描原表。
- MySQL 8.0+ 才原生支持
PIVOT（实际叫PIVOT语法但需配合TABLE函数，极少用） - PostgreSQL 用
crosstab()需额外扩展，且要求输入严格有序 - SQL Server 的
PIVOT要求列名硬编码，动态列得靠动态 SQL
用条件聚合（CASE WHEN + SUM）最通用也最可控
这是跨数据库兼容性最好、逻辑最清晰的方式，核心是：对每个目标列，用 CASE WHEN 把符合条件的行映射为 1，其他为 0，再用 SUM 累加。
假设表 orders 有字段 user_id、status（值为 'pending'/'shipped'/'completed'），要统计每个用户的各状态订单数：
SELECT user_id, SUM(CASE WHEN status = 'pending' THEN 1 ELSE 0 END) AS pending_count, SUM(CASE WHEN status = 'shipped' THEN 1 ELSE 0 END) AS shipped_count, SUM(CASE WHEN status = 'completed' THEN 1 ELSE 0 END) AS completed_count FROM orders GROUP BY user_id;
- 必须用
SUM或COUNT，不能只写CASE——否则每组只返回一行，但值是 NULL 或单个 1，没聚合效果 -
ELSE 0很关键：漏掉会导致该状态为 NULL，SUM(NULL)结果还是 NULL，不是 0 - 如果状态值不确定（比如含空格或大小写混杂），先在
WHERE或CASE内用TRIM(UPPER(status))统一处理
遇到动态列名（比如状态值来自配置表）怎么办
纯 SQL 无法自动展开未知列名，必须靠应用层拼接 SQL 或用存储过程生成语句。例如 PostgreSQL 中可写函数动态构造 SELECT 字段，但执行前仍需预知所有可能状态值。
更现实的做法是：先查出所有有效状态值
SELECT DISTINCT status FROM orders WHERE status IS NOT NULL;
再用这些结果在代码里生成对应数量的 CASE WHEN 分支。Python 示例片段：
statuses = ['pending', 'shipped', 'completed']
case_clauses = [f"SUM(CASE WHEN status = '{s}' THEN 1 ELSE 0 END) AS {s}_count" for s in statuses]
sql = f"SELECT user_id, {', '.join(case_clauses)} FROM orders GROUP BY user_id"
- 千万别用字符串拼接处理用户输入的状态值——必须白名单校验或参数化绑定
- 如果状态种类超过 20 个，生成的 SQL 会很长，某些旧版 MySQL 有
max_allowed_packet限制，需提前调大 - Oracle 用户注意：
CASE内字符串要用单引号，且不能用双引号别名（得用AS "pending_count"）
性能和索引怎么配才不慢
这类查询本质是全表扫描 + 内存聚合，GROUP BY 字段和 CASE 中的判断字段共同决定是否能走索引。
- 最优索引是复合索引：
(user_id, status)—— 覆盖查询所需全部字段，避免回表 - 如果只建了
status单列索引，MySQL 可能选它，但GROUP BY user_id还是要排序，效果打折 - 数据量超百万后，考虑物化中间结果：建汇总表每天凌晨跑一次
INSERT INTO order_status_summary ... SELECT ... GROUP BY - PostgreSQL 用户可启用
enable_hashagg = off强制用 sort-based aggregation，有时比 hash 更稳（尤其内存不足时）
真正容易被忽略的是 NULL 处理和状态值一致性——线上表常有脏数据，status 字段为空或乱码，会导致某列统计永远为 0，但你根本不知道漏了哪些值。
