sql不支持运行时动态替换group by字段，本质是预设逻辑分支；union all拼接固定分组最稳妥，需严格对齐各子查询的select列、类型、顺序与别名，并用where控制分支开关。
SQL 本身不支持运行时动态替换 GROUP BY 后的字段名——这不是 MySQL 特有，PostgreSQL、SQL Server 同样在解析阶段就锁定分组列。所谓“动态切换”，本质是预设逻辑分支，靠条件控制哪条路径生效。
用 UNION ALL 拼接固定分组查询最稳妥
适合业务维度明确、组合有限（通常 ≤ 4 种）的场景。关键不是拼得快，而是对齐严。
- 每个子查询必须显式写出完整
SELECT列：类型一致、顺序一致、别名一致；例如都返回group_type、group_key、cnt -
WHERE条件控制分支开关，如WHERE @mode = 1，优化器通常能跳过未命中分支的扫描，但别依赖它自动剪枝 - 不能指望外层统一补字段：某分支要查部门名称，就得在对应子查询里
JOIN dept，而不是留到外面再LEFT JOIN - MySQL 8.0+ 可配合
WITH提前算好明细，避免重复扫描，但 CTE 本身不解决分组字段动态问题
CASE WHEN 写死在 GROUP BY 里能用，但限制极多
MySQL 5.7+ 开启 ONLY_FULL_GROUP_BY 后，SELECT 和 GROUP BY 中的 CASE WHEN 表达式必须字面完全一致（空格、换行、函数调用都不能差）。
- 不能用别名：
GROUP BY group_dim会报错，必须重复整个CASE WHEN块 - 所有分支返回类型最好统一，比如
YEAR(order_date)返回整数，region是字符串，就得显式转成CAST(region AS CHAR)，否则隐式转换可能出错 - 非法参数值（如
@group_by = 'xxx'）会让所有不匹配行归入NULL组，容易误统计，建议加HAVING group_key IS NOT NULL过滤 - PostgreSQL 允许
GROUP BY引用SELECT别名，但 MySQL 不行，跨库迁移时这点常被忽略
拼接完整 SQL 字符串是唯一真动态方案，但风险自担
必须由应用层（Python/Java）或存储过程完成，数据库原生不提供运行时重写语法的能力。
- MySQL 的
PREPARE+EXECUTE只允许参数化WHERE值，GROUP BY字段必须硬拼进字符串，且需校验白名单（如IN ('region', 'product_type', 'month')），否则就是 SQL 注入入口 - PostgreSQL 的
format('%I', col_name)能安全插值，但依然要先查元数据或硬编码白名单，不能直接信任用户输入 - 拼出来的 SQL 无法被查询缓存复用，执行计划每次都要重新生成，高频调用时性能波动明显
- 权限更难管控：执行动态 SQL 需要
EXECUTE权限，比普通SELECT权限敏感得多
真正容易被忽略的点是：动态分组往往伴随着指标口径变化（比如按部门算人均订单，按产品算次均客单价），而这些逻辑很难塞进同一个 CASE WHEN 或 UNION ALL 结构里。这时候，与其硬凑 SQL，不如把聚合逻辑下沉到应用层做，尤其当数据量可控、且需要叠加复杂条件判断时。
