使用Dapper调用存储过程时，输出参数为何提前被赋值？

别担心，这个现象其实是SQL Server Profiler的“小把戏”，并不是真的在执行存储过程前就给输出参数赋值了！

背后的原因：Profiler的捕获逻辑 #

你在Profiler里看到的这段语句：

declare @p0 int
set @p0=115
exec SearchStuff @rowCount=@p0 output
select @p0

其中的set @p0=115是Profiler自己添加的内容，用来展示存储过程执行完成后输出参数的最终值，而不是执行前就给参数赋了值。

实际的执行流程是这样的：

• Dapper发送的请求只是告诉SQL Server：执行SearchStuff存储过程，并且@rowCount是一个输出参数。
• SQL Server执行存储过程时，会在过程内部给@rowCount赋值（比如通过set @rowCount = @@ROWCOUNT这类逻辑）。
• Profiler为了能捕获并展示输出参数的最终结果，自动生成了一个局部变量@p0，用它来承接输出参数的值，最后通过select @p0把结果显示出来。所以你看到的115其实是存储过程执行完成后@rowCount的最终值，不是执行前就存在的。

验证这个逻辑的小方法 #

你可以在你的SearchStuff存储过程开头加一行打印语句：

print '存储过程开始时@rowCount的值：' + ISNULL(cast(@rowCount as varchar), 'NULL')

执行后查看SQL Server的消息窗口，会看到存储过程启动时@rowCount的值是NULL（如果你的参数没有设置默认值的话），这就证明执行前并没有被赋值，Profiler里的赋值只是它用来展示结果的手段。

Dapper这边的正确获取方式 #

你只需要在执行完ExecuteReader后，通过Dapper的DynamicParameters获取值就可以拿到正确的行计数：

var rowCount = p.Get<int>("@rowCount");

内容的提问来源于stack exchange，提问作者Ian Warburton