c# - LINQ-to-SQL 中的多个 where 子句和 && 运算符有什么区别？

Question

看起来我可以写一个 where x.a==1 && x.b==1 as

where x.a==1
where x.b==1

据我所知，后者变成了 .Where(x => x.a == 1).Where(x => x.b ==1)，但这如何转化为 DB？哪个在优化方面会更好？我总是可以从探查器查看执行的查询，但这很难概括，而更像是我不想依赖的单一经验观察。

使用反射器遍历 System.Linq 命名空间是另一种选择，但那样我们就会错过让许多人免于将时间花在同一件事上的机会。如果我没有得到任何答案，我会这样做。

Answer 1

好的，这是我经过一段时间的 Reflector 输出后的发现。 LINQ-to-Objects 结合连续的 where使用 WhereArrayIterator 时的谓词或 WhereListIterator导致它几乎表现得像 && 运算符，但不完全一样:

当您使用 x.a==1 && x.b==1 时where 子句转换为 Func<TSource, bool>看起来像这样:

bool daspredicate(TSource x)
{
    return x.a==1 && x.b==1
}

但是，当您使用连续的 Where 子句时，性能会受到轻微影响，至少从非 JITted IL 方面来看是这样。以下是合并后代码的样子:

bool predicate1(TSource x)
{
     return x.a==1;
}
bool predicate2(TSource x)
{
     return x.b==1;
}
bool daspredicate(TSource x)
{
    return predicate1(x) && predicate2(x);
}

如您所见，这涉及额外的函数调用开销。除非 JIT 内联函数，否则这可能会非常昂贵。我确信它在这方面做得很好，但我们现在知道如果我们自己组合 Where 语句，JIT 的工作会变得容易得多，除非有必要。

不过，在 SQL 方面，查询是相同的。甚至在执行之前，调试器都会将查询对象评估为相同的 SQL 语句。我不能在 Linq 命名空间中走得太远，因为事情看起来要复杂得多，但由于查询是相同的，所以与上面的 LINQ-to-objects 示例不同，应该没有惩罚。

编辑:我见过多个 where 语句在 SQL Server 上导致嵌套子查询的实例。为了安全起见，我认为最好坚持使用单个 where 语句。