SQL Server 客户端统计结果很差

Question

我刚刚分析了对特定 SQL Server 存储过程的调用。它非常慢，所以我决定分析它。

结果令人困惑：

1. 执行过程需要 1 分 24 秒。
2. 同时执行两个相同的调用需要 2 分 50 秒。显然，正在发生一些错误的阻塞和上下文交换。
3. 当打开实际执行计划并运行一个调用时，需要 4 分 48 秒。客户端统计信息现在告诉我总执行时间是 3000 毫秒。

发生了什么？

实际执行计划真的会干扰那么多吗？

这意味着在某处应该有一个警告，表明执行时间要长得多，而且统计信息也很差。

该过程的规模并不大，但具有令人讨厌的复杂性：游标、五级嵌套选择、临时表、子过程和函数调用。

Answer 1

网络上有大量文章讨论为什么使用游标是一种不好的做法，应该尽可能避免使用。根据数据库设置，在全局命名空间中注册了一个游标，这使得并发几乎不可能 - 您的 proc 的 2 个实例花费恰好两倍的时间是绝对正常的。游标和锁定的性能是另一个考虑点。话虽如此，即使是对带有标识列的临时表进行 while 循环，也可能是比游标更好的解决方案。

我的经验是打开实际执行计划总是会增加一些时间 - 我注意到计划越复杂，效果就越大（所以我猜它与处理它的 SSMS 非常相关）......但在你的情况下，效果看起来比我预期的要大，所以可能还有其他事情发生。