Question

所以我写了一个Linq查询，运行需要16秒。决定查看查询计划是什么，所以我从Linq到SQL Profiler得到了它，查询只需要2秒就可以运行。叹息

在花了大量时间进行操作并最终使用SQL Server Profiler后，我发现Linq2SQL正在使用sp_executesql来运行查询。我知道它应该提高性能，因为它更有可能重复使用执行计划......但似乎选择了一个可怕的执行计划。

更奇怪的是，如果我加入一个特定的表，它只会变慢，我不知道为什么这个特定的表导致了问题。

编辑只是为了澄清这里的实际问题：

它实际上是在进行不同的查询。一个是，基本上，

SELECT col1, col2, ... FROM table1, table2 WHERE table1.val IN (1234, 2343, 2435)

另一个是

EXEC sp_executesql 'SELECT col1, col2, ... FROM table1, table2 WHERE table1.val IN (@p1, @p2, @p3)', 
N'@p0 int,@p1 int,@p2 int,@p3 int',
@p0=1234, @p1=2343, @p3=2435

Answer 1

您的问题并非源于sp_executesql的使用，因此绕过它（您无法解决）将无法解决您的问题。我建议你阅读Erland Sommarskog的优秀文章：

<强> Slow in the Application, Fast in SSMS?
Understanding Performance Mysteries

这将让您深入了解为什么您会获得性能差异，如何诊断并始终如一地重现它，以及最后如何解决它。

Answer 2

如果完全相同的查询从一个应用程序或服务器快速，但从另一个应用程序或服务器缓慢，它通常都是关于执行计划。执行计划是服务器用于运行查询的蓝图。该计划应该创建一次，然后重用于仅在参数值上有所不同的所有查询。

不同的执行计划可能导致差异性能差异，因此100的因素并不罕见。作为第一步，检查执行计划是否不同。探查器事件performance -> showplan xml记录计划。

如果计划不同，可能的原因可能是会话选项，例如ansi nulls：

SET ANSI_NULLS

另一种可能性是不同的登录（蓝图包含安全信息，因此每个安全上下文都有自己的一组缓存执行计划。）

清除计划缓存的最简单方法是重新启动SQL Server服务。还有clear the entire query plan cache的高级命令：

DBCC FREEPROCCACHE

P.S。如果您的存储过程根据参数值执行不同的操作，则值得查看parameter sniffing。但是，由于您从分析器复制完全相同的过程，我假设慢速和快速调用的参数相同。

Answer 3

回答你的问题......

不，你不能......

你能强迫Linq2SQL不使用sp_executesql吗？

3 个答案: