group by后不能用#{}，必须用${}或动态sql白名单校验，因#{}仅预编译值而group by需列名；直接使用${}有sql注入风险，推荐硬编码白名单+分支控制。

GROUP BY 后不能用 #{} 参数占位符

MyBatis 的 #{} 只对值做预编译转义，而 GROUP BY 后要的是列名（标识符），不是值。直接写 GROUP BY #{groupField} 会报错或被当成字符串字面量，MySQL 可能返回单行、PostgreSQL 直接拒绝解析。

常见错误现象：查询结果只有一行、字段名被引号包裹、报错 SQLCODE -29（InterSystems IRIS）或 ERROR 1054 (42S22)（MySQL “Unknown column”）。

根本原因在于 SQL 解析阶段就需确定分组结构，运行时变量无法参与语法树构建。所以必须在拼 SQL 字符串前完成字段合法性校验。

用白名单枚举合法字段最安全

前端传来的 groupField 值（如 "region"、"status,category"）必须严格匹配预设集合，否则拒掉。别图省事用正则模糊匹配，比如 ^[a-zA-Z_][a-zA-Z0-9_]*$ —— 它放行 user_id; DROP TABLE users 这种看似“合法标识符”的恶意串。

推荐做法是服务端硬编码白名单，再用 switch 或 Map 映射：

• "region" → 对应 SQL 片段 "region"
• "region,category" → 对应 "region, category"
• "DATE(created_at)" → 单独校验函数调用，仅允许 ^DATE\([^)]+\)$ 这类固定模式

MyBatis 中用 <choose><when test="groupField == 'region'">region</when></choose> 控制分支，每个分支里写死字段名，不拼接用户输入。

用 GROUP BY 1 这类位置序号有硬伤

虽然 GROUP BY 1 或 GROUP BY 1,2 能绕过字段名校验，但代价明显：

• SELECT 列顺序一变，分组逻辑就错，上线后容易因重构崩掉
• 可读性差，后续维护者得反查 SELECT 列表才能看懂分组意图
• 某些数据库（如 SQL Server）不支持位置号用于 GROUP BY，兼容性风险高
• 没法和 HAVING 配合做条件过滤，因为 HAVING 里还得写字段名，不能写位置号

它只是“能跑”，不是“该用”。仅建议临时调试或极简内部工具中应急，生产环境别碰。

松散索引扫描对动态分组很敏感

MySQL 的 Using index for group-by 优化依赖索引字段与 GROUP BY 字段严格对齐。一旦你动态切换分组字段，原来为 region 设的联合索引（INDEX idx_region_status (region, status)）对只按 status 分组就失效，可能触发全表扫描。

所以别指望一个索引通吃所有动态组合。实际部署时得按高频分组路径建索引，例如：

• 常按 region 分组 → 单列索引 INDEX idx_region (region)
• 常按 region, category 分组 → 联合索引 INDEX idx_region_cat (region, category)
• 避免建 (region, category, status) 这种宽索引，除非三者同时出现频率极高

动态分组不是加个开关就行，背后是索引设计、查询计划、权限控制三件事绑在一起。漏掉任何一环，性能或安全都会出问题。