如何解决LINQ Where 子句常量表达式优化
为了节省一些周期,我重写了一些数据库访问代码。我的主要目标是尽可能多地对我的 LINQ 查询进行服务器端评估。 为了做到这一点,我替换了这个:
data = ...some LINQ...
if(condition){
data = data.Where(element => filter-condition)
}
这样:
data = ...some LINQ...
.Where(element => !condition || filter-condition)
condition
在这种情况下是一个不依赖于当前元素的表达式。所以你可以说它在整个查询过程中实际上是一个常数,因为它总是对 data
中的所有元素求值为真,或者对所有元素求值为假。
另一方面,filter-condition
是一个依赖于当前元素的表达式,正如您对通常的 Where 子句条件所期望的那样。
这种优化很有效,因为它可以在数据库上使用 SQL 进行服务器端评估,而且 LINQ to SQL 编译器足够智能,甚至可以在我的 condition
评估为 false 时短路生成的 SQL .
我的问题是,如果不在服务器端的 SQL 中评估此代码会发生什么。假设我会执行以下操作:
data = ...some LINQ...
.AsEnumerable() //Enforces client-side query evaluation
.Where(element => !condition || filter-condition)
现在我的 Where 子句在客户端进行评估,这在功能方面不是问题。当然,客户端执行的性能更弱。但是我之前所做的自定义优化呢?为我的数据序列中的每个元素评估 condition
是否存在性能损失?或者客户端的 LINQ 是否也足够智能,可以将“常量”表达式 condition
短路?
解决方法
或者客户端的 LINQ 是否也足够智能,可以短路“常量”表达式条件?
有点。 ||
在 C# 中总是得到短路评估,但客户端上的 LINQ 没有任何类型的查询优化器,因此将对每个实体评估 !condition || filter-condition
谓词。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。