SQL Server sp_ExecuteSQL 和执行计划
我有一个查询,它在 SQL Server Management Studio 中运行得非常快,但在 sp_ExecuteSQL 下运行时运行得非常慢。
这是否与在 sp_ExecuteSQL 下运行时未缓存执行计划有关?
I have a query which is super fast in SQL Server Management Studio and super slow when run under sp_ExecuteSQL.
Is this to do with caching of execution plans not happening when run under sp_ExecuteSQL?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
否。
您可以查看两个执行计划并使用以下查询对它们进行比较。
sp_executesql
版本的objtype
为“prepared”No.
You can see both execution plans and compare them using the following query.
The
sp_executesql
version will have anobjtype
of "prepared"经历过同样的行为。 (设置选项等于)
常规查询生成并行计划并使用 sp_executesql 生成串行计划。
vs
我设法通过修改使用的视图获得最佳结果,因为它包含例如始终预期的数据的左连接。 (转换为 INNER join )
现在,常规查询选择与使用 sp_executesql 获得的计划相同的计划,并且性能要好得多。
Experienced the same behaviour. ( set options equal )
Regular Query producing parallel plan and using sp_executesql it produced a serial plan.
vs
I managed to obtain an optimal result modifying the used view because it contained e.g. left joins for data that was always expected. ( converted to INNER join )
Now the regular query picks the same plan as the one obtained using sp_executesql and performance is way better.
我通过更新统计信息解决了 SSMS 中的即席 TSQL 和 sp_executesql 之间查询计划的差异。这是一个简单的查询,两次触及同一个表。
更新一些表的统计数据
I resolved a difference in query plan between ad-hoc TSQL in SSMS and sp_executesql by updating stats. This was a simple query that touched the same table twice.
UPDATE STATISTICS sometable