必须校验GROUP BY字段合法性并禁用动态拼接，否则引发SQL注入、全表扫描或性能崩塌；应预建计算列、用参数化查询、白名单校验及EXPLAIN验证执行计划。
存储过程里用 CONCAT 拼 GROUP BY 字段会触发 SQL 注入
直接把用户输入拼进 GROUP BY 子句，比如 SET @sql = CONCAT('SELECT ... GROUP BY ', @field)，就等于把数据库的语法控制权交给了外部输入。一旦 @field 是 user_id, (SELECT SLEEP(5)) 或更危险的 user_id; DROP TABLE logs --，执行时就会连带注入语句一起跑。
MySQL 不会校验 @field 是不是合法列名，只当它是字符串原样塞进去；PostgreSQL 和 SQL Server 同样不拦截，只是报错时机不同——有的静默失败，有的直接崩。
- 必须先查
INFORMATION_SCHEMA.COLUMNS确认该字段真实存在于目标表中 - 字段名不能含空格、点号、括号等特殊字符，否则要手动加反引号或双引号包裹
- 拼出来的 SQL 中，
SELECT列表里的非聚合字段必须和GROUP BY子句完全一致，漏一个就触发ONLY_FULL_GROUP_BY报错
MySQL 存储过程中 GROUP BY 无法使用变量或函数作为分组依据
GROUP BY @col 或 GROUP BY YEAR(created_at) 在存储过程里写出来，MySQL 解析器会在编译阶段报错或静默失效。它不认为 @col 是列引用，而是当作未声明变量；而 YEAR() 这类函数会导致索引完全失效，哪怕 created_at 上有索引，也会强制全表扫描 + filesort。
常见误判是“只要能执行就不算错”，但结果往往全归一组（逻辑错误），或者响应时间从 50ms 涨到 8s（性能崩塌）。
- 别在
GROUP BY里用任何运行时计算，包括CASE WHEN包裹整个字段（除非你真想让所有行进同一组） - 如果业务需要按年/月分组，提前建好
order_year、order_month计算列并加索引，然后直接GROUP BY order_year - MySQL 8.0+ 支持生成列（generated column），可设为 STORED + 索引，比函数更安全
动态 SQL 在存储过程中执行效率不可控
每次调用都要走 PREPARE → EXECUTE → DEALLOCATE 流程，比普通查询多出解析、计划缓存查找、权限校验三道开销。尤其在高并发场景下，容易卡在 Waiting for table metadata lock 或触发 max_prepared_stmt_count 限制。
更隐蔽的问题是：优化器对动态 SQL 的执行计划选择更保守。传入参数值分布偏斜（比如某 tenant_id 只有 3 条记录，另一 tenant_id 有 200 万条），可能导致本该走索引的查询被选成全表扫描。
- 务必用
EXPLAIN FORMAT=TREE带真实参数执行一次，别只测默认值或空参 - 避免在循环里反复
PREPARE同一条语句；可改用静态 SQL + 参数化WHERE过滤来缩小数据集 - 若分组前数据量预估超 10 万行，应在存储过程开头加
SELECT COUNT(*)判断，超阈值则退化为异步任务或缓存返回
MyBatis 等 ORM 中 ${} 拼 GROUP BY 是高危操作
XML 里写 GROUP BY ${groupFields} 看似方便，但 ${} 是纯字符串替换，不经过 JDBC 预编译。前端传 department, (SELECT version())，后端就真去执行这个子查询。
这类写法在代码审计中属于“一眼红”漏洞，CI/CD 流水线应配置规则禁止 ${} 出现在 GROUP BY、ORDER BY、TABLE NAME 等位置。
- 白名单校验是底线：只允许
['user_id', 'dept_id', 'region', 'product_type']这类固定枚举 - 校验必须在 DAO 层入口做，不能依赖前端传来的“看起来像字段名”的字符串
- 若必须支持任意字段，改用
CASE WHEN映射（如GROUP BY CASE WHEN #{mode} = 'user' THEN user_id ELSE dept_id END），由数据库驱动绑定参数，杜绝拼接
CONCAT('GROUP BY ', @field)。 
