不能直接用GROUP BY配合列名变量，因SQL标准不支持；动态表头需用CASE WHEN+SUM实现条件聚合，列名由AS定义；分组值不确定时须由应用层拼SQL，PIVOT等语法仍属静态定义。
为什么不能直接用 GROUP BY 配合列名变量
SQL 标准不支持把列名写成变量或表达式传给 GROUP BY，比如 GROUP BY @group_col 或 GROUP BY CONCAT('type_', level) 都会报错。动态表头本质是「行转列」+「分组聚合」的组合需求，硬套 GROUP BY 无法生成列名可变的结果集。
用 CASE WHEN + SUM 实现条件聚合是唯一可靠路径
真正能控制输出列结构的方式，是显式写出每一列的聚合逻辑：对每个目标分组值，用 CASE WHEN 判断是否命中，再套一层 SUM（或 COUNT、AVG）做条件计数。数据库执行时，这些表达式被当成独立标量列处理，最终结果自然带出你定义的列名。
常见错误现象：SUM(IF(status='active', 1, 0)) 在 MySQL 可用，但 IF 是 MySQL 特有函数；跨数据库应统一用 CASE WHEN：
SELECT dept, SUM(CASE WHEN status = 'active' THEN 1 ELSE 0 END) AS active_count, SUM(CASE WHEN status = 'inactive' THEN 1 ELSE 0 END) AS inactive_count FROM employees GROUP BY dept;
- 列名（如
active_count）完全由你定义，就是“动态表头”的来源 - 所有分支必须覆盖全集，否则漏掉的行会算作
0（ELSE 0不可省） -
SUM比COUNT更安全：后者遇到NULL会被跳过，而CASE中未匹配分支默认返回NULL，导致统计偏少
当分组值不确定时，必须靠应用层拼 SQL
如果要按用户自定义标签、动态时间段、或 API 传入的枚举值分列（比如前端选了 ['iOS', 'Android', 'Web']），SQL 本身无法自动展开列。这时候没有“纯 SQL 解法”，必须由 Python/Java 等应用代码生成对应数量的 CASE WHEN 子句。
示例逻辑（Python 伪代码）：
dims = ['iOS', 'Android', 'Web']
case_sql = ', '.join([
f"SUM(CASE WHEN platform = '{d}' THEN 1 ELSE 0 END) AS {d.lower()}_count"
for d in dims
])
sql = f"SELECT region, {case_sql} FROM logs GROUP BY region"
- 千万别试图用存储过程循环拼接——多数生产环境禁用动态 SQL，且难以调试
- 注意单引号转义：若
dims来自用户输入，必须参数化或白名单校验，否则 SQL 注入 - 列数过多（如上百个维度）会导致查询计划膨胀，MySQL 有
max_allowed_packet限制，PostgreSQL 有statement_timeout压力
替代方案：PIVOT 不是银弹，要看数据库支持度
SQL Server 和 Oracle 有 PIVOT 语法，PostgreSQL 用 crosstab() 扩展，MySQL 完全不支持。即使可用，它们仍要求「列名列表」在写 SQL 时就固定，本质上还是静态定义，只是写法更紧凑。真正动态的场景下，PIVOT 的子查询仍需提前知道有哪些值，绕不开应用层预查或双重查询。
容易被忽略的一点：所有条件聚合都隐含一个假设——分组键（如 dept）和透视键（如 status）是正交的。如果某 dept 下根本不存在 'archived' 状态，则对应列全为 0，不会消失。想让列随数据自动增减，只能放弃 SQL 单次查询，改用两步：先查出所有可能值，再生成并执行新 SQL。
