SQL Server ODBC 性能损失？答案

【问题标题】：SQL Server ODBC performance penalty?SQL Server ODBC 性能损失？
【发布时间】：2011-02-14 21:52:37
【问题描述】：

这很奇怪，但我希望有人能帮助我。

我有一个存储过程调用，它需要大约 42 秒才能运行 - 当从通过 ODBC 连接连接的应用程序调用时。但是，如果我在 SSMS（Sql Server Management Studio）中运行相同的调用，则执行只需 10 或 15 秒……正如跟踪记录的那样。

这似乎不是网络问题。我只将大约 1200 条记录传回给客户端——无论如何，我给你的时间直接来自跟踪持续时间字段……所以 SQL Server 处理同一个调用的时间要长 3 到 4 倍——当通过 ODBC 调用完成。我可以一遍又一遍地重现这一点。更有趣的是，ODBC 调用的读取和写入（从跟踪中获取）略高，但 CPU 使用率是 SSMS 调用的 3 或 4 倍。

还有其他存储过程被称为同一进程的一部分，它们似乎不会以相同的方式受到影响......或者至少不会受到相同程度的影响。

我们使用的是 SQL Server 2005

对这里发生的事情有什么想法吗？

【问题讨论】：

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

标签： sql-server performance sql-server-2005 stored-procedures odbc

【解决方案1】：

可能是您从 SSMS 中的“预热”缓存中提取数据。尝试在 SSMS 中的存储过程调用之前使用这些行运行它，看看它是否运行得一样快：

CHECKPOINT
GO
DBCC DROPCLEANBUFFERS
GO
DBCC FREEPROCCACHE
GO

-- Your SQL begins here

正如@Martin 所说，它也可能是参数嗅探的结果。 Here is a good SO post 超过了这一点。

【讨论】：

哇...这有很大的不同！似乎清除了所有缓存。我的 SSMS 查询花了一分钟多的时间（您可能会这样），但现在 ODBC 连接要快得多！那里有什么？
@Clinemi - 如果清除计划缓存解决了问题，那么我肯定会怀疑参数嗅探。
是的，清算现金应该让双方的事情变得更长。每次测试时，您是否将完全相同的参数传递给存储过程？
另外，如果您清除了缓存，通过 SSMS 运行 proc，然后通过 ODBC 重新运行它，那么 ODBC 运行将针对预热的缓存。
我相信肯定是参数嗅探。执行上述代码后，我首先运行了 SSMS 调用——重建了查询计划并花费了很长时间。但是，在那之后，ODBC 和 SSMS 调用都很快。 SSMS 仍然约为 10-15 秒，但 ODBC 约为 4 秒！我在这些调用中使用了相同的参数，更改参数可能会改变一些事情，但症状看起来像参数嗅探。谢谢！

【解决方案2】：

听起来像第一次连接时间。你能用两个电话重现这个问题，而第二个电话只需要时间吗？也可能值得用另一个库来计时，看看它是否不同。

【讨论】：