安全动态聚合需白名单校验函数名、QUOTENAME()处理字段表名、CASE枚举聚合逻辑、参数化HAVING条件，并确保sp_executesql语句一致以复用执行计划。
为什么直接拼接聚合函数名会触发SQL注入
动态聚合查询最常踩的坑，就是把用户传入的函数名（比如 COUNT、SUM、AVG）直接拼进SQL字符串。一旦攻击者传入 'COUNT(*) FROM sys.tables; DROP TABLE users; --' 这类输入，拼出来的语句就可能执行任意DDL或DML。根本原因在于：数据库不区分“函数名”和“代码片段”，只要语法合法，就照单全收。
如何安全地支持动态聚合函数选择
核心原则是：函数名不能由用户输入决定，必须来自预设白名单；所有可变字段（如列名、表名）必须用 QUOTENAME() 处理；聚合逻辑本身必须参数化，不参与拼接。
- 用
CASE WHEN显式枚举合法聚合函数，例如：CASE @AggFunc WHEN 'COUNT' THEN COUNT(*) WHEN 'SUM' THEN SUM(price) END，而不是@AggFunc + '(price)' - 若必须支持任意列名（如用户选“按城市统计”或“按品类统计”），先校验该列是否真实存在于目标表中，再用
QUOTENAME(@ColumnName)包裹 - 表名同理——查
sys.tables或information_schema.tables确认存在，再套QUOTENAME() - 避免在
sp_executesql的参数定义字符串里漏掉N前缀，例如N'@col NVARCHAR(128)'，否则 Unicode 列名可能被截断或乱码
GROUP BY 和 HAVING 动态化时的陷阱
当用户能自定义分组字段或筛选条件时，GROUP BY 子句最容易成为注入入口。错误写法是直接拼 'GROUP BY ' + @GroupByCol；正确做法是只允许从白名单字段中选择，并强制用 QUOTENAME() 处理。
-
HAVING条件不能拼接原始用户值，例如'HAVING COUNT(*) > ' + @MinCount是危险的——应改用参数化：HAVING COUNT(*) > @MinCount - 如果
HAVING需要动态列（如HAVING AVG(sales) > 1000），同样只允许白名单列 +QUOTENAME()，且聚合函数部分仍走CASE枚举 - 注意
GROUP BY后的列必须出现在SELECT列表中（SQL Server严格模式），动态拼接时容易漏检，建议提前用元数据验证
性能与缓存：sp_executesql 不等于自动复用执行计划
很多人以为用了 sp_executesql 就万事大吉，其实执行计划能否复用，取决于生成的SQL文本是否完全一致。动态聚合查询中，哪怕只是 @AggFunc 值不同（COUNT vs SUM），生成的最终SQL字符串就不同，导致每次编译新计划。
- 高频调用场景下，应尽量收敛聚合函数种类（例如只开放
COUNT和SUM），减少计划碎片 - 避免在SQL字符串中嵌入带时间戳或GUID的临时变量名，这会让计划无法复用
- 日志中务必记录实际生成的
@sql字符串（而非仅参数值），便于后续排查慢查询和计划未复用问题
