GROUP BY后不能直接拼变量，因SQL解析在执行前完成，变量值运行时才确定；须通过白名单校验后字符串拼接，或用MyBatis等ORM的条件标签安全实现。
GROUP BY 后面不能直接拼变量？
不能。标准 SQL 语法里 GROUP BY 后必须是列名、表达式或位置序号，不接受运行时变量。你写 GROUP BY @group_col 或 GROUP BY '${col}' 会直接报错，比如 MySQL 报 ERROR 1054 (42S22): Unknown column 'xxx' in 'group statement'，PostgreSQL 则提示 column "xxx" does not exist。
根本原因是 SQL 解析发生在执行前，而变量值在运行时才确定——解析器根本看不到它该替换成哪个字段。
- 硬编码字段名（如
GROUP BY user_id）能过解析，因为列名静态可见 - 字符串拼接进 SQL 语句（如
"GROUP BY " + colName）可行，但属于动态 SQL，要自己防注入、校验字段白名单 - 用
GROUP BY 1这类位置序号可以绕开字段名，但可读性差、易错，且要求SELECT列顺序和分组逻辑强绑定
MySQL / PostgreSQL 动态 GROUP BY 的安全写法
核心就一条：把字段名当“标识符”处理，而不是值。不能用参数占位符 ? 或 $1，得靠服务端拼接，但必须严格过滤输入。
例如用户传入 group_by=region，你要检查它是否在预设白名单里：['region', 'category', 'status', 'DATE(created_at)']。允许函数表达式？那就单独校验，比如匹配 ^DATE\([^)]+\)$。
- Python 示例（用
sqlalchemy.text）：allowed_cols = {'region', 'category', 'status'} if group_col not in allowed_cols: raise ValueError("Invalid group field") query = text(f"SELECT {group_col}, COUNT(*) FROM orders GROUP BY {group_col}") - Node.js（
pg）中绝不能写GROUP BY $1，而要：const allowed = new Set(['region', 'category']); if (!allowed.has(groupCol)) throw new Error('Bad group field'); const query = `SELECT ${groupCol}, COUNT(*) FROM orders GROUP BY ${groupCol}`; - PostgreSQL 支持
GROUP BY CUBE或GROUPING SETS做多维组合，但那是固定结构，不是动态字段选择
MyBatis 的 <bind> 和 <choose> 怎么用
MyBatis 是少数能把动态 GROUP BY 写得相对干净的 ORM。它不靠字符串拼接，而是用 XML 标签控制 SQL 片段生成，字段名仍是字面量，没注入风险。
关键不是 <bind>（它只做变量赋值），而是 <choose> + <when> 控制分支。每个 <when test="groupField == 'region'"> 里写死一个合法字段名。
-
<bind>可用于预处理，比如把date_str转成DATE(created_at)字符串，但最终仍要放进<choose>分支里使用 - 别用
${groupField}直接插值——除非你已在外层彻底校验过，否则等于敞开 SQL 注入大门 - 如果字段来自用户输入且组合复杂（如支持嵌套 JSON 字段），建议改用视图或物化列预计算，避开动态 SQL
为什么 GROUP BY 动态化后 COUNT DISTINCT 容易出错
不是语法错，是语义漂移。比如你动态切到 GROUP BY DATE(created_at)，但 COUNT(DISTINCT user_id) 在每天粒度下是对的；一旦切到 GROUP BY region，同样这句就变成“每个地区去重用户数”，结果含义完全变了——但 SQL 本身不报错，数据却可能误导人。
- 前端传来的
group_by和select_fields必须同步校验，比如选了region就不该允许created_at出现在 SELECT 中（除非加聚合） - 某些数据库（如 ClickHouse）对
GROUP BY表达式缓存不友好，频繁切换不同字段会导致计划缓存失效，QPS 下降明显 - 最麻烦的是 NULL 处理：不同字段 NULL 分布差异大，
GROUP BY region可能有大量 NULL 组，而GROUP BY category可能没有——聚合结果分布会突变，监控告警阈值得跟着调
动态 GROUP BY 真正难的从来不是怎么拼 SQL，而是字段语义一致性、NULL 边界、以及下游 BI 工具能否正确理解每次请求的维度含义。这些没法靠语法检查发现，得靠字段元数据约束和查询前的 schema 验证。
