11

我在带有一些参数的 sql select 语句中遇到性能缓慢的问题，对于同一个查询，使用这种sp_executesql方式执行这个选择需要两倍于内联方式的时间。

问题是在 sp_execute-way sql server 中没有使用最佳执行计划。尽管计划不同，但似乎在这两种情况下都正确使用了表的索引。我真的不明白为什么性能如此不同。

我的原始查询更复杂，但为了弄清楚发生了什么，我将原始查询简化为具有 3 个表和 2 个连接的选择。主要区别是在优化中使用哈希匹配，我真的不知道这是什么意思，但这是我能看到的唯一区别。

最优计划（哈希匹配，超过 3 秒）

在此处输入图像描述

错误的计划（没有哈希匹配，与上面相同的索引，超过 12 秒）

在此处输入图像描述

  1. 我认为我的问题不是“参数嗅探”，在我的情况下，对于所有不同的参数值，查询总是很慢，因为执行计划总是不正确的。

  2. OPTION (RECOMPILE)没有帮助，sp_executesql继续运行缓慢并且内联方式需要更多时间（因为查询总是编译执行计划）

  3. 表的统计信息已更新

  4. 我必须使用sp_executesql方式，因为报告服务似乎将选择封装在sp_executesql调用中

有人知道为什么会sp_executesql生成与内联查询不同的（错误的）执行计划吗？

编辑：查询没有使用相同的索引我猜是因为执行树不一样，sqlserver随意使用索引，附加你可以找到新的执行计划来强制使用相同的索引，性能现在更差，从慢查询12秒到15分钟以上（我已经取消）。我真的对更快地运行这个特定查询不感兴趣，因为我说这不是我正在处理的真正查询，我想弄清楚为什么内联查询和sp_executesql-之间的执行计划如此不同询问。

有什么神奇的选择sp_executesql可以正常工作吗？:)

最佳 在此处输入图像描述

减缓 在此处输入图像描述

4

1 回答 1

3

我的理解是 sp_executesql 在第一次执行后保留了一个缓存计划。后续查询可能使用了错误的缓存计划。您可以使用以下命令清除整个SQL Server 过程缓存。

    DBCC FREEPROCCACHE

http://msdn.microsoft.com/en-us/library/ms174283.aspx

于 2014-08-19T22:01:40.033 回答