SQL Server触发器中禁止使用EXEC/sp_executesql，因其属副作用操作；应改用IF/CASE分支的静态SQL实现动态路由，或移至应用层、CDC等外部机制处理。
SQL Server 触发器里不能直接用 EXEC 或 sp_executesql
触发器中执行动态 SQL 是常见需求，比如根据插入行的值决定往哪张归档表写数据。但多数人一试就报错：The EXECUTE permission was denied on the object 'sp_executesql' 或更直接的 Invalid use of a side-effecting operator 'EXECUTE STRING' within a function（即使没在函数里，SQL Server 也严格限制触发器中的执行上下文）。根本原因是：SQL Server 不允许在触发器作用域内调用会改变执行环境或隐式开启新会话的操作——EXEC 和 sp_executesql 都被归为此类。
这不是权限问题，也不是配置没开，而是引擎层的硬性限制。试图用 EXEC('INSERT ...') 会直接编译失败，连触发器都创建不了。
替代方案：用条件逻辑 + 静态 SQL 覆盖所有分支
真正可行的做法是放弃“拼字符串再执行”，转而用 CASE、IF 和明确的表名/列名写出所有可能路径。SQL Server 触发器支持完整的流程控制，只要目标语句本身是静态可解析的就行。
- 把“动态表名”转换为多个
IF @table_name = 't_log_2024'分支，每个分支写一条确定的INSERT INTO t_log_2024 ... - 避免在
SELECT列表里用EXEC()，改用CASE WHEN计算字段值 - 如果分支太多（如按月分表超 12 张），考虑用视图或合成表统一接口，让上层逻辑不感知物理表切换
例如：想根据 INSERTED.status 决定插入 orders_active 还是 orders_archived，就写：
IF EXISTS (SELECT 1 FROM INSERTED WHERE status = 'active')
INSERT INTO orders_active SELECT * FROM INSERTED WHERE status = 'active';
IF EXISTS (SELECT 1 FROM INSERTED WHERE status = 'archived')
INSERT INTO orders_archived SELECT * FROM INSERTED WHERE status = 'archived';MySQL 触发器更严格：连 PREPARE/EXECUTE 都不支持
MySQL 的触发器上下文完全禁止任何预编译和执行动态语句的操作。文档明确写着：PREPARE, EXECUTE, and DEALLOCATE PREPARE are not permitted in stored functions or triggers。这意味着哪怕你绕过 SQL Server 的限制，在 MySQL 里也走不通。
可行路径只有两条：
- 用事件（
EVENT）或外部脚本定期扫描标志位表，再执行动态逻辑（但失去实时性） - 把动态路由逻辑提到应用层或存储过程里，触发器只做轻量记录（如写入
pending_tasks表），由其他机制消费
试图在 MySQL 触发器里写 SET @sql = CONCAT('INSERT INTO ', @tbl, ' ...'); PREPARE stmt FROM @sql; 会直接报错：ERROR 1356 (HY000): Trigger cannot have PREPARE statement。
真正需要动态 SQL 的场景，该换架构而不是硬刚触发器
当业务要求“插入 A 表时，自动根据字段值往 N 张不同结构的表写数据”，这已超出触发器的设计边界。触发器本质是声明式钩子，不是动态调度器。
- 把路由规则配置化（如存进
routing_rules表），用应用层查规则 + 拼 SQL 执行，比在数据库里硬塞逻辑更可控 - 用 CDC（如 Debezium）捕获变更，下游服务做动态分发，解耦且可监控
- 如果必须在库内处理，用存储过程封装主逻辑，触发器只调用它（注意：SQL Server 允许触发器调用存储过程，但该过程内部仍不能含
EXEC）
最常被忽略的一点：触发器里的事务不可分割。一旦动态 SQL 执行失败，整个原始 DML 就回滚——但没人告诉你，那个“动态 SQL”甚至根本没机会运行。
