SQL Server启用CLR集成需先执行sp_configure启用clr enabled选项并设数据库TRUSTWORTHY ON（或证书签名），程序集须用.NET Framework 4.8及以下编译，类方法需public static且参数为SqlTypes，禁止非沙箱操作，依赖项须单独注册，UNSAFE需显式权限。
SQL Server中启用CLR集成的必要步骤
默认情况下SQL Server禁用CLR集成，直接创建程序集会报错 Msg 6263, Level 16, State 1: CREATE ASSEMBLY for assembly 'xxx' failed because assembly 'xxx' is not authorized for PERMISSION_SET = UNSAFE。必须先开启服务器级配置并设置数据库信任级别。
- 执行
sp_configure 'show advanced options', 1; RECONFIGURE;再运行sp_configure 'clr enabled', 1; RECONFIGURE; - 目标数据库需设为
TRUSTWORTHY ON（仅开发环境可接受），生产环境更推荐用证书签名方式授权，避免全局信任风险 - 若程序集含
UNSAFE权限（如调用Win32 API、文件IO），数据库必须使用AUTHORIZATION dbo创建，且不能是tempdb或系统库
编译C#类库时的关键约束
SQL Server CLR宿主环境不是完整.NET运行时，不支持大多数BCL类型和线程模型。常见失败原因不是代码逻辑错，而是违反了SQL Server的托管代码沙箱限制。
- 项目目标框架必须为
.NET Framework 4.8或更低（SQL Server 2019及之前不支持.NET Core/.NET 5+） - 类和方法必须标记为
public static，且方法参数/返回值只能是SQL Server原生支持的类型（如SqlInt32、SqlString、SqlDateTime，不能用string或int直接替代） - 禁止使用
Console.WriteLine、Thread.Sleep、HttpClient、Assembly.Load等非沙箱安全操作；日志可用SqlContext.Pipe.Send()输出到SSMS消息窗口
在存储过程中调用CLR函数或过程的写法
CLR代码不能直接“被存储过程调用”，而是先注册为SQL Server内置对象（标量函数、表值函数、存储过程、聚合），再由T-SQL按常规方式调用。不存在“从T-SQL里执行一段C#代码”的自由度。
- 创建程序集：
CREATE ASSEMBLY MyAssembly FROM 'C:\path\to\MyAssembly.dll' WITH PERMISSION_SET = SAFE;（根据实际权限选SAFE/EXTERNAL_ACCESS/UNSAFE） - 创建对应T-SQL包装对象，例如：
CREATE PROCEDURE dbo.usp_DoWork @input SqlString AS EXTERNAL NAME MyAssembly.[MyNamespace.MyClass].DoWork; - 调用时完全等同于普通存储过程：
EXEC dbo.usp_DoWork @input = N'test';，传参规则和错误处理与T-SQL过程一致
调试和部署时最常踩的坑
错误信息往往模糊（如 Assembly not found 或 Could not load file or assembly），实际原因多与依赖链或权限粒度有关，而非代码本身。
- 所有依赖的.NET程序集（如Newtonsoft.Json）也必须单独用
CREATE ASSEMBLY注册，且版本号、公钥令牌必须严格匹配——用sn -Tp xxx.dll核对 -
UNSAFE ASSEMBLY要求数据库拥有者（OWNER）具备UNSAFE ASSEMBLY服务器权限，普通db_owner角色不够 - 修改C#代码后重新部署，必须先
DROP ASSEMBLY，再CREATE ASSEMBLY；SQL Server不会自动覆盖，残留旧版本会导致调用异常
CLR集成不是通用扩展机制，适合CPU密集型计算（如正则批量处理、加密解密）、需要复用现有.NET算法逻辑的场景。一旦涉及网络、文件、配置读取等外部交互，维护成本和权限复杂度会陡增，此时应优先考虑外部服务+SQL Agent作业或API网关方案。
