在SQL触发器中使用动态SQL极其危险：绕过权限校验、逃逸SQL注入防护、难以审计回滚，且破坏事务一致性与可观测性；应优先采用静态逻辑、变更消息队列或白名单+QUOTENAME()等安全替代方案。
直接说结论：在SQL触发器里用动态SQL，等于把数据库的执行权交给字符串拼接逻辑——它既绕过权限校验，又逃过SQL注入防护，还难以审计和回滚。
动态SQL在触发器中会绕过调用者权限
触发器默认以定义者的权限运行，不是当前用户的权限。一旦里面嵌了 sp_executesql 或 EXEC，哪怕低权限用户只是插入一条普通日志，也可能触发高权限操作。
- 例如：一个可被所有人写的
logs表，配了触发器去动态更新employees表薪资字段，攻击者只需往logs插入特定 payload 就能提权 - 权限检查只发生在触发器入口，不穿透到动态语句内部；
sp_executesql执行时不会重新校验调用上下文 - DBA 很难通过常规权限审计发现这类越权路径，因为静态分析看不到实际执行的语句
拼接用户输入极易引发SQL注入
触发器无法像应用层那样做参数绑定，而 INSERTED 或 DELETED 中的数据可能来自不可信来源（如前端表单、第三方同步、ETL脚本），一旦直接拼进字符串就危险。
- 典型错误写法：
SELECT @cmd = 'INSERT INTO audit_log VALUES (''' + USER + ''', ''' + (SELECT TOP 1 payload FROM inserted) + ''')' - 如果
payload是test'; DROP TABLE users; --，整个语句就变成两条独立命令 - MyBatis 或 C# 的
#{} / SqlParameter在触发器里完全不可用；你只能靠手动转义或白名单，但 SQL Server 的QUOTENAME()只保表名/列名，保不住值
动态SQL让触发器失去可观测性和事务一致性
动态生成的语句不进查询计划缓存，也不出现在 sys.dm_exec_query_stats 中；更麻烦的是，它天然脱离主事务的原子性保障。
- 执行失败时，整个事务会回滚，但错误堆栈只显示“在触发器中执行动态SQL失败”，看不出原始拼接内容
- 若动态SQL写入另一数据库的日志表，主库事务回滚后，那条日志已落盘，形成数据不一致
- SQL Server 的
TRY...CATCH在触发器中捕获不到所有错误类型（比如编译期错误），且不能ROLLBACK外部事务 - MySQL 8.0+ 的
DECLARE EXIT HANDLER同样受限于触发器执行环境，无法处理语法错误或权限拒绝
替代方案比硬扛动态SQL更可靠
绝大多数触发器里的动态需求，其实有更安全、更可控的解法，没必要死守字符串拼接。
- 值过滤类逻辑：用
IF UPDATE(col)+CASE WHEN替代动态 WHERE；用COALESCE(NEW.val, OLD.val)避免空值判断拼接 - 多表写入类逻辑：改用“写轻量变更消息表 + 后台作业消费”，把复杂逻辑移出事务边界
- 审计日志类逻辑：直接用
INSERT INTO audit_log (...) SELECT USER, GETDATE(), i.* FROM inserted i，不用拼字符串 - 真需要动态结构（如表名）：提前建好映射表，用
JOIN查出目标对象，再用QUOTENAME()包裹，且仅限白名单内的标识符
最常被忽略的一点是：触发器本身已是隐式执行路径，再叠一层动态SQL，等于给问题加了双重模糊性——你既不知道谁触发了它，也不知道它到底执行了什么。宁可多写几条静态触发器，也别用一个“万能”动态触发器包打天下。
