使用sp_executesql的非最佳执行计划

Mig*_*una 11 sql-server reporting-services sp-executesql

我在使用一些参数的sql select语句中遇到性能下降的问题,对于同一个查询,使用sp_executesql内联方式需要两倍的时间执行此选择.

问题是在sp_execute-way中sql server没有使用最佳执行计划.虽然计划不同,但似乎在两种情况下都正确使用了表的索引.我真的不明白为什么表现如此不同.

我的原始查询更复杂,但是为了弄清楚发生了什么,我将原始查询简化为具有3个表和2个连接的选择.主要区别在于最佳使用Hash Match,我真的不知道这个的含义但是我能看到的唯一区别.

最佳计划(哈希匹配,超过3秒)

在此输入图像描述

错误的计划(没有哈希匹配,索引与上面相同,超过12秒)

在此输入图像描述

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

  2. OPTION (RECOMPILE)没有帮助,sp_executesql继续变慢和内联方式需要更多时间(因为查询总是编译执行计划)

  3. 表的统计信息已更新

  4. 我必须使用sp_executesql方式,因为似乎报告服务封装了select中的sp_executesql调用

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


编辑:查询没有使用相同的索引我想这是因为执行树不一样,sqlserver随意取索引,附加你可以找到新的执行计划强制使用相同的索引,性能现在甚至最差,从在慢查询中12秒到超过15分钟(我已取消).我真的没有兴趣以更快的速度运行这个特定的查询,因为我说这不是我正在处理的真正的查询,我想弄清楚的是为什么执行计划在内联查询和sp_executesql- 之间是如此不同查询.

这有什么神奇的选择sp_executesql吗?:)

最佳 在此输入图像描述

在此输入图像描述

Ahz*_*Ahz 3

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

    DBCC FREEPROCCACHE
Run Code Online (Sandbox Code Playgroud)

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