动态SQL中字段名不能直接用于GROUP BY，需字符串拼接+执行（如EXEC或PREPARE/EXECUTE），并校验列名合法性防注入；多字段分组须用STRING_AGG/GROUP_CONCAT组装；无ORDER BY则结果顺序未定义；频繁硬解析导致性能下降，应优先静态SQL或手动缓存计划。
动态SQL拼接时字段名被当成字符串字面量
直接把变量写进 GROUP BY 后面，比如 GROUP BY @group_col，SQL Server 会报错“必须声明标量变量”，MySQL 则可能静默地按字面值分组（即所有行都归到同一组）。本质是 SQL 解析器在编译阶段不识别变量占位，它只认真实列名或表达式。
- 必须用字符串拼接 +
EXEC（SQL Server）或PREPARE/EXECUTE（MySQL）触发重编译 - 拼接前务必校验
@group_col是否为合法列名（防注入），可用白名单或系统视图INFORMATION_SCHEMA.COLUMNS检查 - MySQL 示例：
SET @sql = CONCAT('SELECT ', @group_col, ', COUNT(*) FROM orders GROUP BY ', @group_col);<br>PREPARE stmt FROM @sql;<br>EXECUTE stmt;<br>DEALLOCATE PREPARE stmt;
存储过程中传入多个分组字段的兼容写法
用户想支持 GROUP BY region, status 或单字段 GROUP BY region，但不能靠简单拼接逗号——空格、括号、关键字（如 ORDER BY）混入会导致语法错误。
- 用临时表或表变量先存合法字段名，再用
STRING_AGG（SQL Server 2017+）或GROUP_CONCAT（MySQL）组装，避免手写逗号逻辑 - SQL Server 示例：
DECLARE @cols NVARCHAR(MAX) = (SELECT STRING_AGG(QUOTENAME(col), ', ') FROM #valid_cols);<br>SET @sql = 'SELECT ' + @cols + ', COUNT(*) FROM t GROUP BY ' + @cols;
- 老版本 SQL Server 可用
FOR XML PATH替代，但要注意结尾多出的逗号需STUFF去掉
动态分组后排序失效或结果不稳定
执行完动态 SQL 返回结果集，发现没按预期排序，甚至两次运行顺序不同。这不是 bug，而是标准行为：SQL 标准规定，**没有 ORDER BY 的查询结果顺序无定义**，动态 SQL 也不例外。
- 必须把排序字段也作为参数传入，并拼进最终语句，不能依赖客户端补排序
- 注意排序方向（
ASC/DESC）要单独校验，别直接拼用户输入——@order_dir必须限定为'ASC'或'DESC' - SQL Server 中若用
OFFSET/FETCH分页，ORDER BY是强制要求，漏写会直接报错
性能陷阱：每次执行都硬解析动态SQL
存储过程里反复拼接并执行 EXEC(@sql)，会导致计划缓存无法复用，高并发下 CPU 升高、编译等待增多。尤其当分组字段变化频繁（如前端下拉选 20 个字段任意组合），缓存命中率趋近于零。
- 优先考虑用静态 SQL +
CASE WHEN模拟动态分组（适用于字段数有限、组合可枚举的场景） - SQL Server 可尝试
sp_executesql配合参数化（但注意：分组字段名本身不能参数化，只能参数化WHERE条件值） - 真正需要动态字段时，至少加一层简单哈希（如
HASHBYTES('SHA2_256', @group_col)）做缓存键，手动管理执行计划复用逻辑
最麻烦的不是拼 SQL，是让不同数据库对同一套字段白名单校验逻辑保持一致；SQL Server 用 sys.columns，MySQL 用 INFORMATION_SCHEMA.COLUMNS，字段名大小写、引号规则、保留字处理全都不一样——别指望一次写完到处跑。
