GROUP BY 后不能直接拼接变量，因SQL标准要求分组字段必须是明确列名或确定表达式；动态分组应通过应用层拼SQL（需白名单校验）、存储过程PREPARE/EXECUTE，或用CASE WHEN枚举有限维度实现。
GROUP BY 后面不能直接拼接变量，这是最常踩的坑
SQL 标准不支持把变量或表达式直接写在 GROUP BY 子句里（比如 GROUP BY @dimension 或 GROUP BY ${col}），执行会报错：Unknown column '@dimension' in 'group statement' 或类似语法错误。这不是 MySQL 特有，PostgreSQL、SQL Server 同样不认——因为 SQL 解析阶段就要求 GROUP BY 的字段必须是明确的列名、序号或确定表达式，不能是运行时才决定的值。
真正能“动态”的路只有一条：在应用层或存储过程里生成完整 SQL 字符串，再执行。硬要在纯 SQL 里“模拟”，只能靠条件分支 + 多个 CASE WHEN 配合固定分组字段，但代价高、可读差、不可扩展。
用 CASE WHEN + 固定 GROUP BY 实现有限维度切换
适用于维度选项少（如 3–5 个）、且能提前枚举的场景。核心思路是：把所有可能的分组字段都用 CASE WHEN 抽出来作为一列，再对这列分组。例如想按 region 或 product_type 动态分组：
SELECT
CASE WHEN @dim = 'region' THEN region
WHEN @dim = 'product_type' THEN product_type
ELSE 'all' END AS group_key,
COUNT(*) AS cnt
FROM sales
GROUP BY group_key;
注意点：
-
@dim必须是会话变量（MySQL）或参数（如 PostgreSQL 的$1），且类型要和目标字段兼容（比如region是字符串，@dim就不能传数字） - 所有
WHEN分支返回值类型必须一致，否则报Illegal mix of collations或类型转换错误 - 无法对
group_key做排序或筛选（如HAVING），因为它是计算列，不是原始列 - 索引基本失效——数据库没法用
region索引加速这个CASE表达式
更靠谱的做法：在应用代码里拼 SQL（Python / Java 示例）
这才是生产环境主流解法。数据库只负责执行确定语句，动态逻辑交给上层控制。
Python（用 sqlite3 或 pymysql）示例：
allowed_dims = ['region', 'product_type', 'sales_rep']
if dimension not in allowed_dims:
raise ValueError("Invalid dimension")
query = f"SELECT {dimension}, COUNT(*) FROM sales GROUP BY {dimension}"
cursor.execute(query)
关键约束：
- 必须白名单校验
dimension，绝不能直接插进 SQL——否则就是 SQL 注入高危漏洞 - 字段名不能带点（如
user.name）、不能含空格或特殊字符，否则需加反引号（MySQL）或双引号（PostgreSQL） - 如果维度来自用户输入，还要过滤掉注释符（
--、/*）和分号（;）
存储过程中用 PREPARE + EXECUTE（MySQL）或动态 SQL（SQL Server）
适合必须在数据库内完成的场景（如报表视图封装）。MySQL 示例：
SET @sql = CONCAT('SELECT ', @dim, ', SUM(amount) FROM sales GROUP BY ', @dim);
PREPARE stmt FROM @sql;
EXECUTE stmt;
DEALLOCATE PREPARE stmt;
风险点很实在：
-
@dim仍需白名单检查，否则CONCAT直接拼出恶意语句 - PREPARE 不能复用跨连接，每次执行都重新解析，性能不如预编译语句
- PostgreSQL 要用
EXECUTE 'SELECT ...' USING ...，SQL Server 用sp_executesql，语法差异大，别照搬 - 错误信息难调试——报错行号指向
EXECUTE行，不是实际 SQL 内容
真正麻烦的从来不是怎么写，而是怎么确保那个动态字段名既合法又安全。漏掉一次校验，就可能让整张表被拖库。
