如何在SQL中依据业务逻辑动态切换聚合维度

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，不如把聚合逻辑下沉到应用层做，尤其当数据量可控、且需要叠加复杂条件判断时。