我们有一个用 C# 编码的 Web 服务，可以多次调用 MS SQL Server 2005 数据库。该代码使用 Using block 结合 C# 的连接池。
在 SQL 跟踪期间，我们看到了对“sp_resetconnection”的许多调用。其中大部分都很短 < 0.5 秒，但有时我们会接到长达 9 秒的通话。
据我所读，sp_resetconnection 与连接池有关，基本上重置打开连接的状态。我的问题:
- 为什么打开的连接需要重置其状态？
- 为什么打这么多电话!
- 什么会导致调用 sp_reset 连接花费大量时间。
这对我来说是个谜，感谢所有帮助!
最佳答案
重置只是重置一些东西，这样您就不必重新连接来重置它们。它清除了 SET 或 USE 操作等连接，因此每个查询都有一个干净的状态。
连接仍在被重用。这是一个 extensive list :
sp_reset_connection 重置连接的以下方面:
- 它重置所有错误状态和数字(如@@error)
- 它停止所有作为执行并行查询的父 EC 的子线程的 EC(执行上下文)
- 它将等待任何未完成的 I/O 操作
- 它将通过连接释放服务器上所有保留的缓冲区
- 它将解锁连接使用的所有缓冲区资源
- 它将释放所有分配给连接的内存
- 它将清除连接创建的任何工作表或临时表
- 它将杀死连接拥有的所有全局游标
- 它将关闭所有打开的 SQL-XML 句柄
- 它将删除所有打开的 SQL-XML 相关工作表
- 它将关闭所有系统表
- 它将关闭所有用户表
- 它将删除所有临时对象
- 它将中止未完成的交易
- 它会在入伍时脱离分布式事务
- 它将减少当前数据库中用户的引用计数；释放共享数据库锁
- 它将释放获得的锁
- 它将释放任何可能已获得的句柄
- 它将所有 SET 选项重置为默认值
- 它将重置@@rowcount 值
- 它将重置@@identity 值
- 它将使用 dbcc traceon() 重置任何 session 级跟踪选项
sp_reset_connection 不会重置:
- 安全上下文，这就是连接池根据确切的连接字符串匹配连接的原因
- 如果您使用 sp_setapprole 输入应用程序角色，因为应用程序角色无法还原
- 事务隔离级别(!)
关于c# - 为什么 C# 连接池有这么多 sp_resetconnections？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/962331/