SQL Server ODBC性能惩罚？

Question

这很奇怪，但我希望有人能帮助我解决问题。 我有一个存储过程调用，从ODBC连接的应用程序中调用需要约42秒才能运行。 但是，如果我在SSMS（Sql Server Management Studio）中运行相同的调用，它只需要10或15秒钟才能执行...如跟踪记录的那样。 这似乎不是网络问题。 我只向客户端传递大约1200条记录 - 无论如何，我给出的时间都来自跟踪持续时间字段...因此，当通过ODBC调用完成相同的调用时，SQL Server处理所需的时间要长3或4倍。 我可以一遍又一遍地重现这个问题。 更有趣的是，从跟踪中获取的读取和写入（来自ODBC调用）稍微高一些，但CPU使用率比SSMS调用高3或4倍。 在同一过程中还有其他存储过程被调用，它们似乎没有以同样的方式受到影响...或者至少没有受到同样程度的影响。 我们正在使用SQL Server 2005。 关于这里发生了什么，有什么想法吗？

- Clinemi

---

可能是参数嗅探问题。检查两个执行计划是否有差异。SSMS 可能会有一些不同的 set 选项，这意味着它不会共享来自其他连接的计划，而是会生成一个新的计划，该计划可能更适合该参数集。 - Martin Smith

Answer 1

可能是因为你正在从SSMS的“预热”缓存中提取数据。在SSMS中调用存储过程之前，请尝试运行以下代码，看看是否能够快速运行：

CHECKPOINT
GO
DBCC DROPCLEANBUFFERS
GO
DBCC FREEPROCCACHE
GO

-- Your SQL begins here

正如@Martin所说，这也可能是参数嗅探的结果。这里有一篇很好的SO帖子对此进行了详细说明。

- Abe Miessler

---

哇...这真的有很大的改善！看起来清除了所有缓存。我的SSMS查询花费了超过一分钟（你可能会预料到），但ODBC连接现在快多了！这是怎么回事？ - Clinemi

@Clinemi - 如果清除计划缓存解决了问题，那么我肯定会怀疑参数嗅探。 - Martin Smith

清除缓存应该对两者都有所帮助。你每次测试时是否传递完全相同的参数给存储过程？ - Abe Miessler

此外，如果您清除了缓存，通过SSMS运行了过程，然后通过ODBC重新运行它，那么ODBC运行将针对已预热的缓存。 - Abe Miessler

我相信这肯定是参数嗅探。在执行上述代码后，我首先运行了SSMS调用 - 它重建了查询计划并花费了很长时间。但是，在那之后，ODBC和SSMS调用都很快。 SSMS仍然约为10-15秒，但ODBC约为4秒！ 我在这些调用中使用了相同的参数，更改参数可能会改变事情，但症状看起来像是参数嗅探。谢谢！ - Clinemi

Answer 2

听起来像是第一次连接。你能否尝试两次调用并仅计时第二次，以重现此问题？另外，值得尝试使用另一个库计时调用，看看是否有所不同。

- Preet Sangha