理解性能的奥秘——应用程序中慢，SSMS中快——收集解决参数嗅探问题的信息

Posted 2020-08-20 發糞塗牆

本文属于《理解性能的奥秘——应用程序中慢，SSMS中快》系列

接上文：理解性能的奥秘——应用程序中慢，SSMS中快（3）——不总是参数嗅探的错

前面已经提到过关于存储过程在SSMS中运行很快，但在应用程序中运行很慢的可能原因：因为ARITHABORT的不同选项会导致不同的缓存词目，另外由于SQL Server使用了参数嗅探导致获得了不同的执行计划。

虽然已经说明了这个现象的原因，但是还没解释：如何定位和解决这个问题？到目前为止，大家都知道了如何快速处理，如果这个问题很紧急，可以直接使用：

EXEC sp_recompile 存储过程名

前面提到过，这个操作会刷新计划缓存。下次存储过程被调用时，会产生新的查询计划。如果通过这种方式可以解决，那么认为这个已经不是问题了。

但是如果问题依旧，那么就需要做更深入的研究，并且不适合再用sp_recompile或者类似的方式去修改存储过程。另外请一直打开显示执行计划的选项以便用于对比和检查，最起码可以获取参数的值（可以通过右键执行计划→【显示执行计划XML】的方式在XML格式的执行计划中搜索ParameterList的值）。这是本节的主题。

在开始本节之前，给个小建议：修改SSMS的默认值，以便因为ARITHABORT的默认值带来困惑。建议把这个值设为OFF。但是与应用程序相同设置确实会有一些小缺点：你可能观察不到与参数嗅探有关的性能问题。但是如果你已经养成了都校验ARITHABORT ON和OFF的结果，那么这个问题就不成问题了。

获取必要的事实：

以上是关于理解性能的奥秘——应用程序中慢，SSMS中快——收集解决参数嗅探问题的信息的主要内容，如果未能解决你的问题，请参考以下文章

理解性能的奥秘——应用程序中慢，SSMS中快——案例：如何应对参数嗅探

理解性能的奥秘——应用程序中慢，SSMS中快——收集解决参数嗅探问题的信息

理解性能的奥秘——应用程序中慢，SSMS中快——SQL Server如何编译存储过程

理解性能的奥秘——应用程序中慢，SSMS中快——案例：如何应对参数嗅探

理解 select poll epoll

深入理解lambda的奥秘