.NET/IIS执行MSSQL查询时挂起，但SSMS中可正常运行的原因排查

这种情况我碰到过不少次，核心问题基本都是SSMS和.NET/IIS应用的运行环境、上下文或者设置不一致导致的，给你列几个最值得优先排查的方向：

• 连接字符串参数差异：最常见的是ARITHABORT设置不同。SQL Server会根据这个参数的值生成不同的执行计划——SSMS默认是开启ARITHABORT ON的，而.NET的默认连接设置里可能是ARITHABORT OFF，这会导致生成的执行计划效率天差地别。另外还要检查事务隔离级别，比如.NET应用是否不小心设置了SERIALIZABLE这种高隔离级别，导致锁等待时间大幅增加，而SSMS默认是READ COMMITTED。

• 参数嗅探与执行计划缓存问题：如果你在SSMS里测试用的参数和.NET实际传递的参数不一样，可能触发参数嗅探——SQL Server缓存了第一次执行的计划，但这个计划对后续不同参数的查询完全不适用，导致执行变慢甚至挂起。另外，也可能是.NET里的参数传递方式导致类型不匹配（比如用AddWithValue传递字符串，SQL Server可能把它当成NVARCHAR而你的索引是VARCHAR，导致索引失效），而SSMS里你手动写的参数类型是对的，所以能用到高效索引。

• 事务范围差异：.NET应用里可能把这个查询包裹在了一个更大的事务中（比如整个HTTP请求的事务），导致查询执行时持有的锁一直不释放，甚至和其他请求的操作产生锁冲突；而你在SSMS里是单独执行查询，没有外层事务，锁用完就释放了，自然不会挂起。

• 数据库用户上下文差异：.NET应用使用的数据库账号和你SSMS登录的账号可能有不同的默认设置，比如ANSI_NULLS、QUOTED_IDENTIFIER这些开关，或者对某些表的统计信息权限不同，这都会影响SQL Server生成执行计划的逻辑。

• 并发与资源竞争：IIS是多并发环境，如果多个请求同时执行这个大查询，会导致数据库的CPU、IO或者锁资源被占满，查询就会排队挂起；而你在SSMS里是单独跑，没有资源竞争，所以10-20秒就完成了。另外也可以看看应用池的线程设置，是否因为线程不足导致请求排队，看起来像是查询挂起。

• 连接池残留问题：连接池里的连接可能残留了之前的状态，比如某个连接的事务没提交就被放回池里，后续.NET请求复用这个连接时，查询就会在一个未提交的事务中运行，锁一直无法释放，最终导致挂起。

备注：内容来源于stack exchange，提问作者James Johnson