SQL Server 触发器中可调用 CLR 函数，但需将其注册为标量或表值函数并在集合操作中使用，严禁直接执行 EXEC 或新建连接；必须设为 EXTERNAL_ACCESS/UNSAFE 权限、避免 I / O 和线程操作，且注意逐行调用性能问题。
SQL Server 触发器里不能直接调用 CLR 函数
SQL Server 的 INSTEAD OF 或 AFTER 触发器内部，不支持直接执行 EXEC、SELECT 调用 CLR 存储过程，也不允许在触发器体中用 CALL 或类似语法“运行”CLR 代码块。这是设计限制：触发器运行在事务上下文内，而 CLR 集成默认被设为 SAFE 权限级别，禁止访问外部资源、线程或大多数 .NET 类型——更别说主动触发另一个 CLR 入口了。
常见错误现象是部署后触发器编译通过，但一触发就报：The context connection is not available in the current environment. 或更直接的：Cannot use SAVE TRANSACTION within a trigger.（其实跟 CLR 无关，但常一起出现，说明你试图在触发器里干超出边界的事）。
- 真正能做的，是把 CLR 编译为
EXTERNAL_ACCESS或UNSAFE级别，并作为标量函数 / 表值函数 / 存储过程注册进数据库 - 然后在触发器里像调用普通 T-SQL 函数一样用它，比如：
SELECT dbo.CalculateRiskScore(Inserted.amount, Inserted.customer_id) - 但注意：标量 CLR 函数会被逐行调用，
Inserted或Deleted是表，必须用CROSS APPLY或子查询包装，否则会隐式循环、性能崩塌
如何让 CLR 函数安全地在触发器中被调用
关键不是“怎么调用”，而是“怎么写这个 CLR 函数”，让它符合触发器环境的约束。核心原则：不打开新连接、不 sleep、不读写文件、不调用 Thread.Start 或 HttpClient。
使用场景很窄：比如对插入的 JSON 字段做校验、计算哈希、解析时间字符串、做简单正则匹配（Regex.Match 在 SAFE 下可用）、查内存字典映射等纯 CPU 操作。
- SQL Server 2017+ 默认禁用 CLR，得先开：
sp_configure 'show advanced options', 1; RECONFIGURE; sp_configure 'clr enabled', 1; RECONFIGURE; - 创建程序集时必须指定权限级别：
CREATE ASSEMBLY MyClrAssembly FROM 0x…… WITH PERMISSION_SET = EXTERNAL_ACCESS;（SAFE最安全，EXTERNAL_ACCESS可读 registry 或网络，UNSAFE基本等于放弃 SQL Server 安全模型） - 函数签名必须是 static、public、返回可映射类型（如
int,string,SqlInt32），参数也得是 SQL 友好类型（避免List<T>、DateTimeOffset）
触发器里调用 CLR 函数的典型写法和坑
别写成这样：DECLARE @v INT = dbo.MyClrFunc(Inserted.value); —— Inserted 是表，不是单值，T-SQL 会报错“无法绑定多部分标识符”。正确做法是把它嵌进集合操作里。
性能影响非常真实：如果 Inserted 一次插 1000 行，而你的 CLR 函数没批处理意识，就会被调用 1000 次，且每次都是独立上下文初始化开销。
- 推荐写法：
SELECT i.*, dbo.ValidateEmail(i.email) AS is_valid FROM Inserted i;（标量函数，适用于字段级简单校验） - 更高效写法（SQL Server 2016+）：
CROSS APPLY dbo.ParseJsonArray(i.payload) AS j;（表值 CLR 函数，适合展开嵌套结构） - 容易踩的坑：
SqlContext.Pipe在触发器中不可用；SqlConnection必须用"context connection=true"，且不能在函数里显式Open()—— 上下文连接由 SQL Server 自动管理 - 调试困难：SQL Server 不允许在触发器中用
System.Diagnostics.Debug.WriteLine，日志只能靠SqlContext.Pipe.Send（仅限存储过程）或写 Windows Event Log（需EXTERNAL_ACCESS）
替代方案比硬上 CLR 更常用也更稳
90% 的所谓“复杂逻辑”，其实用原生 T-SQL 就能解决，比如窗口函数、STRING_AGG、OPENJSON、TRY_CONVERT，甚至临时表 + 循环（虽然不优雅，但比 CLR 部署失败强）。
真需要外部能力（比如调第三方 API、跑 Python 模型），触发器不是第一选择。SQL Server Agent 作业 + 监控表变更、或应用层拦截 INSERT/UPDATE，才是更可控的路径。
- 如果坚持用 CLR，优先封装成表值函数（TVF），配合
APPLY，避免标量函数的 RBAR（Row-By-Agonizing-Row）惩罚 - 所有 CLR 程序集上线前，必须在目标版本 SQL Server 上用相同 .NET Framework 版本重新编译（比如 SQL Server 2019 默认只认 .NET Framework 4.7.2，不是 .NET Core/.NET 5+）
- 最易忽略的一点：触发器里调用的 CLR 函数，其异常不会自动 rollback 整个事务 —— 除非你在函数里抛出
SqlException，否则可能静默失败，数据已改但逻辑没生效
