GROUP BY后不能使用变量或字符串，必须为列名或表达式；动态分组需拼接完整SQL并执行，且须白名单校验字段防注入，或改用视图/CTE/应用层分组等更安全方案。
GROUP BY 字段不能写成变量，直接拼接会报错
SQL 标准里 GROUP BY 后面必须是列名或表达式，不接受变量或字符串。比如你写 GROUP BY @group_col 或 GROUP BY 'region'，MySQL 会报 Unknown column 'region' in 'group statement'，PostgreSQL 则提示 column "region" does not exist。这不是语法糖缺失，而是解析阶段就拒绝——SQL 引擎在编译时就要确定分组依据的物理列，没法运行时“查表”再决定。
动态拼接 GROUP BY 的唯一可靠方式是拼完整 SQL 字符串
必须把整个查询（含 SELECT、FROM、GROUP BY）组装成字符串，再用执行函数调用。不同数据库写法略有差异：
- MySQL：用
PREPARE+EXECUTE，注意参数只能用于WHERE值，不能替代列名；GROUP BY字段必须硬拼进字符串 - PostgreSQL：用
EXECUTE+format()，支持安全插值，但需手动校验字段名是否合法（防 SQL 注入） - SQL Server：用
sp_executesql，同样要求列名拼进字符串，参数仅限值绑定
示例（PostgreSQL）：
DO $$
DECLARE
group_by_col TEXT := 'category';
sql TEXT;
BEGIN
-- 必须白名单校验，避免注入
IF group_by_col NOT IN ('category', 'region', 'status') THEN
RAISE EXCEPTION 'invalid group column: %', group_by_col;
END IF;
sql := format('SELECT %I, COUNT(*) FROM orders GROUP BY %I', group_by_col, group_by_col);
EXECUTE sql;
END $$;
用视图或 CTE 代替动态 SQL 更安全，但灵活性受限
如果维度数量固定（比如只在 region / product_type / month 三者间切换），优先考虑预定义逻辑：
- 建一个带所有常用分组字段的视图，查询时用
CASE WHEN控制输出列，但GROUP BY仍得写死 - 用 CTE 预聚合到最细粒度（如按
region, product_type, month），再外层GROUP BY按需 rollup，但会多一次扫描 - 应用层做分组：查出明细后用 Python/Java 分组统计，适合数据量不大或需要复杂逻辑的场景
这类方案绕开了动态 SQL 的风险，但代价是无法真正“动态切换”——要么提前写好所有组合，要么把计算压力推给应用。
真正要警惕的是权限和执行计划缓存问题
动态 SQL 不只是写法麻烦，还有两个容易被忽略的副作用：
- 每个拼出来的 SQL 字符串都是新语句，数据库不会复用执行计划（尤其 MySQL 的 query cache 已废弃，PG 的 plan cache 也按文本匹配），高频切换维度会导致硬解析飙升
- 执行动态 SQL 的账号必须对涉及的所有表和字段有 SELECT 权限，而不能只靠角色继承——因为解析时字段名是字符串，权限检查发生在运行时，不是预检阶段
如果你的维度字段来自用户输入（比如前端下拉框），务必加字段白名单校验，别只靠 ESCAPE 或正则过滤，否则一个 region, (SELECT password FROM users LIMIT 1) 就可能触发子查询注入。
