SQL Server居然也能调 C# 代码 ?

一：背景

1. 讲故事

前些天看到一个奇怪的然也 Function 函数，调用的然也是 C# 链接库中的一个 UserLogin 方法，参考代码如下：

复制

CREATE FUNCTION dbo.clr_UserLogin( @name AS NVARCHAR(100),然也 @password AS NVARCHAR(100))RETURNS INTASEXTERNAL NAME asmXXX.[xxx.CLRFunctions].UserLogin;

GO

1.2.3.4.5.6.7.8.9.10.

这就让我产生了很大的兴趣，众所周知 SQLSERVER 是然也 C++ 写的，那这里的然也 C++ 怎么和 C# 打通呢？而且 C# 是一门托管语言，需要 JIT 将其 native 化，然也这个 JIT 又在哪里呢？然也带着这些疑问一起研究下吧。

二：互通原理研究

1. 一个简单的然也例子

首先写一段简单的 C# 代码，然后把它编译成 dll。然也

复制

namespace AQMN.Bussiness{

public class UserFunctions

{ public static string UserLogin(string username,然也 string password) { var random = new Random(); var isSuccess = random.Next() % 2 == 0; return isSuccess ? "登录成功" : "登录失败"; } }}1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.

接下来需要做的就是数据库参数配置，开启 CLR 支持，然也并且指定某个数据库支持 unsafe 模式。然也

复制

EXEC sp_configure clr enabled,然也 1;RECONFIGURE;

GO

ALTER DATABASE MyTestDB SET TRUSTWORTHY ON;

GO

1.2.3.4.5.6.7.

为了能够调到 C# 的 UserLogin 方法，需要 SQLSERVER 先导入这个程序集，源码下载然也然后再以 Function 映射其中方法即可，然也参考代码如下：

复制

CREATE

ASSEMBLY clr_AQMN_Bussiness

FROM D:\net6\SQLCrawl\AQMN.Bussiness\bin\Debug\AQMN.Bussiness.dllWITH PERMISSION_SET = UNSAFE;

GO

CREATE FUNCTION dbo.clr_UserLogin( @username AS NVARCHAR(100), @password AS NVARCHAR(100))RETURNS NVARCHAR(100)ASEXTERNAL NAME clr_AQMN_Bussiness.[AQMN.Bussiness.UserFunctions].UserLogin;

GO

1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.

创建完了之后，可以观察 assembly 开头的几个系统视图。

复制

SELECT * FROM sys.assembliesSELECT * FROM sys.assembly_files;SELECT * FROM sys.assembly_modules;1.2.3.4.

看起来没啥问题，接下来调用一下刚才创建的 clr_UserLogin 函数。

复制SELECT dbo.clr_UserLogin(Njack,N123456) AS StateGO 101.2.

从图中看登录结果是随机的，说明 C# 的 Random 函数起到了作用，非常有意思。

2. WinDbg 观察

从案例的运行结果看，推测在 SQLSERVER 中应该承载了一个 CLR 运行环境，那是不是这样呢？可以用 WinDbg 附加到 ​​sqlservr.exe​​ 进程，用 lm 观察下模块加载情况。

复制

0:092>

lm

start end module name

...

00007ff8`d3960000 00007ff8`d3aaf000 clrjit (deferred)00007ff8`de040000 00007ff8`deb02000 clr (deferred)

...

0:092> !

eeversion

4.8.4300.0

free

Server mode with 12

gc heaps

SOS Version: 4.8.4300.0

retail build

1.2.3.4.5.6.7.8.9.10.11.12.13.

从输出看果然加载了 clr 和 clrjit 动态链接库，当前还是 gc server 模式，🐂哈。

接下来再验证一个问题，既然 clr_UserLogin 函数会显示 登录成功/登录失败，那必然会调用 C# 的高防服务器 UserLogin 方法，可以在 WinDbg 中对 UserLogin 方法下一个断点观察一下这个调用过程。

复制

0:090> !name2ee AQMN.Bussiness!AQMN.Bussiness.UserFunctions.UserLoginModule: 00007

ff87ee37988

Assembly: AQMN.Bussiness, Versinotallow=1.0.0.0, Culture=neutral, PublicKeyToken=nullToken: 0000000006000001MethodDesc: 00007

ff87ee38020

Name: AQMN.Bussiness.UserFunctions.UserLogin(System.String, System.String)JITTED Code Address: 00007

ff87ec560d0

0:090> bp 00007

ff87ec560d0

0:090>

g

1.2.3.4.5.6.7.8.9.10.11.

从输出信息看 UserLogin 方法已经被 JIT 过了，用 bp 下完断点之后，继续 g，然后在 SSMS 上再次执行查询就可以成功命中啦。

复制

0:090>

k

# Child-

SP RetAddr Call Site

00 000000df`1557ae48 00007ff8`7ee500b6 0x00007ff8

`7ec560d0

01 000000df`1557ae50 00007ff8`7ec55ef1 0x00007ff8

`7ee500b6

02 000000df`1557aeb0 00007ff8`de04222e 0x00007ff8

`7ec55ef1

03 000000df`1557af00 00007ff8`a2b79ff3 clr!UMThunkStub+0x6e04 000000df`1557af90 00007ff8`a2b741bd sqllang!CallProtectorImpl::CallWithSEH<AppDomainCallTraits,void,FunctionCallBinder_3<void,void (__cdecl*)(void (__cdecl*)(void * __ptr64),void * __ptr64,enum ESqlReturnCode * __ptr64),void (__cdecl*)(void * __ptr64),void * __ptr64,enum ESqlReturnCode * __ptr64> const >+0x2305 000000df`1557afc0 00007ff8`a2b6bfc4 sqllang!CallProtectorImpl::CallExternalFull<AppDomainUserCallTraits,void,FunctionCallBinder_3<void,void (__cdecl*)(CXVariant * __ptr64,CXVariant * __ptr64,CClrLobContext * __ptr64),CXVariant * __ptr64,CXVariant * __ptr64,CClrLobContext * __ptr64> const >+0x2dd06 000000df`1557b130 00007ff8`a2bda602 sqllang!CAppDomain::InvokeClrFn+0xd407 000000df`1557b1d0 00007ff8`aef51ee7 sqllang!UDFInvokeExternalImpl+0xb7208 000000df`1557b7e0 00007ff8`9de52e24 sqlTsEs!CEsExec::GeneralEval4+0xe709 000000df`1557b8b0 00007ff8`9de52d64 sqlmin!CQScanProjectNew::EvalExprs+0x18f0a 000000df`1557b920 00007ff8`9ddd8759 sqlmin!CQScanProjectNew::GetRow+0x980b 000000df`1557b970 00007ff8`9ddc73de sqlmin!CQScanLightProfileNew::GetRow+0x190c 000000df`1557b9a0 00007ff8`a25e51d7 sqlmin!CQueryScan::GetRow+0x800d 000000df`1557b9d0 00007ff8`a32a78b2 sqllang!CXStmtQuery::ErsqExecuteQuery+0x3d80e 000000df`1557bb40 00007ff8`a2bc2451 sqllang!CXStmtSelect::XretDoExecute+0x3420f 000000df`1557bc10 00007ff8`a2b733d3 sqllang!UM_LoopbackForStatementExecution+0x19110 000000df`1557bd00 00007ff8`de48e940 sqllang!AppDomainCallback<FunctionCallBinder_5<void,void (__cdecl*)(CXStmtQuery * __ptr64,CCompExecCtxtStmt const * __ptr64,CMsqlExecContext * __ptr64,unsigned long * __ptr64,enum ESqlReturnCode * __ptr64),CXStmtQuery * __ptr64,CCompExecCtxtStmt const * __ptr64,CMsqlExecContext * __ptr64,unsigned long * __ptr64,enum ESqlReturnCode * __ptr64> >+0x2311 000000df`1557bd40 00007ff8`de48e193 clr!ExecuteInAppDomainHelper+0x4012 000000df`1557bd80 00007ff8`a2b79f39 clr!CorHost2::ExecuteInAppDomain+0x3a013 000000df`1557c0a0 00007ff8`a2b73a86 sqllang!CallProtectorImpl::CallWithSEH<AppDomainCallTraits,long,MethodCallBinder_3<long,ICLRRuntimeHost,long (__cdecl ICLRRuntimeHost::*)(unsigned long,long (__cdecl*)(void * __ptr64),void * __ptr64) __ptr64,unsigned long,long (__cdecl*)(void * __ptr64),void * __ptr64> >+0x2914 000000df`1557c0d0 00007ff8`a2b6c2d0 sqllang!CallProtectorImpl::CallExternalFull<AppDomainCallTraits,long,MethodCallBinder_3<long,ICLRRuntimeHost,long (__cdecl ICLRRuntimeHost::*)(unsigned long,long (__cdecl*)(void * __ptr64),void * __ptr64) __ptr64,unsigned long,long (__cdecl*)(void * __ptr64),void * __ptr64> >+0x18615 000000df`1557c170 00007ff8`a32a72f4 sqllang!CAppDomain::LoopbackForStatementExecution+0x18016 000000df`1557c230 00007ff8`a32a79ad sqllang!CXStmtQuery::XretCLRExecute+0x10417 000000df`1557c2a0 00007ff8`a25e4a65 sqllang!CXStmtSelect::XretExecute+0x4a18 000000df`1557c370 00007ff8`a25e44a8 sqllang!CMsqlExecContext::ExecuteStmts<1,1>+0x8f219 000000df`1557cf10 00007ff8`a25e3a2c sqllang!CMsqlExecContext::FExecute+0x9361a 000000df`1557def0 00007ff8`a25ee67b sqllang!CSQLSource::Execute+0xc5c1b 000000df`1557e3d0 00007ff8`a25ed815 sqllang!process_request+0xca61c 000000df`1557ead0 00007ff8`a25ed5ef sqllang!process_commands_internal+0x4b71d 000000df`1557ec00 00007ff8`b1e46523 sqllang!process_messages+0x1d61e 000000df`1557ede0 00007ff8`b1e46e6d sqldk!SOS_Task::Param::Execute+0x2321f 000000df`1557f3e0 00007ff8`b1e46c75 sqldk!SOS_Scheduler::RunTask+0xa520 000000df`1557f450 00007ff8`b1e6b160 sqldk!SOS_Scheduler::ProcessTasks+0x39d21 000000df`1557f570 00007ff8`b1e6aa5b sqldk!SchedulerManager::WorkerEntryPoint+0x2a122 000000df`1557f640 00007ff8`b1e6afa4 sqldk!SystemThreadDispatcher::ProcessWorker+0x3ed23 000000df`1557f940 00007ff8`f6d86fd4 sqldk!SchedulerManager::ThreadEntryPoint+0x3b524 000000df`1557fa30 00007ff8`f865cec1 KERNEL32!BaseThreadInitThunk+0x1425 000000df`1557fa60 00000000`00000000 ntdll!RtlUserThreadStart+0x211.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.25.26.27.28.29.30.31.32.33.34.35.36.37.38.39.40.41.

果然是一个 request 请求，然后达到了托管方法 UserLogin，顶部的三行线程栈可以用 !clrstack 具意下。

复制

0:090> !

clrstack

OS Thread Id: 0x6df4 (90)

Child SP IP Call Site

000000df1557ae48 00007ff87ec560d0 AQMN.Bussiness.UserFunctions.UserLogin(System.String, System.String)000000df1557ae50 00007ff87ee500b6 DynamicClass.SQLCLR_Eval(IntPtr, IntPtr, IntPtr)000000df1557aeb0 00007ff87ec55ef1 DomainBoundILStubClass.IL_STUB_ReversePInvoke(Int64, Int64, Int64)000000df1557bf18 00007ff8de04222e [ContextTransitionFrame: 000000df1557bf18]1.2.3.4.5.6.7.8.

三：总结

SQLSERVER 内嵌了 CLR，让 sqlservr 进程成了一种托管和非托管的混合环境，不知道是好事还是坏事，在我的分析旅程中这种混合环境下看过太多的堆破坏问题，但不管怎么说，托管的 C#，VB，F# 可以助 SQLSERVER 更加强大。