.net – 为什么当参数作为参数传递时,sp_executesql运行速度较慢

前端之家收集整理的这篇文章主要介绍了.net – 为什么当参数作为参数传递时,sp_executesql运行速度较慢前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
查询1 :(闪电快)
sp_executesql "select * from tablesView where Id = 1"

查询2 :(太慢)

sp_executesql "select * from tablesView where Id = @Id",N"@Id int",@Id=1

tablesView – 包含多个连接的视图

LINQ始终将查询转换为Query2表单,因此性能非常差.

问题:我需要query2缓慢的原因,如果有一个解决方案.
和LINQ的一个决议.

– – 补充评论

性能命中绝对是因为使用排序函数(row_number)的2列,但是我无法避免它们需要它们.

解决方法

我要在这里出去,假设你有很多行ID = 1.

如果没有,请更正我.

sql Server正在处理您的查询缓慢的一个可能的原因是它查看查询并执行:

hmm,I wonder what he’s going to pass for that parameter.
is it going to be 1? where I have about a gazillion rows?
or perhaps 1742,where I have just 3
I just don’t know,I better do a table scan to be sure to produce an execution plan that will cover all my bases

如果列或列集合具有较低的选择性(即,唯一值的数量远远小于行数),则sql Server有时会还原为tablecan或类似的,以确定性地获取所有行.

至少这是我的经验.特别是当在日期范围内选择具有时间限制数据的表格时,我看到了相同的行为,执行一个WHERE dt< = @dt AND dt> = @dt来获取@dt在一段时间内的所有行在那一行的时间,还原到表扫描,然后当我把实际的日期作为一个文字,它运行得更快.

这里的问题是选择性,sql Server不知道如何在为您的语句构建执行计划时最好地满足所有情况,所以它会尝试猜测.

尝试添加查询提示以指定参数的典型值,即:

sp_executesql "select * from tablesView where Id = @Id option (optimize for (@id = 1742))",@Id=1
原文链接:https://www.f2er.com/mssql/75577.html

猜你在找的MsSQL相关文章