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

看来我可以写一个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 命名空间是另一种选择，但这样我们就会错过避免许多人在同一件事上花费时间的机会。如果我没有得到任何答案，我会这样做。

好的，这是我在检查反射器输出一段时间后的发现。 LINQ 到对象结合了连续的where使用时的谓词WhereArrayIterator or WhereListIterator导致它的行为几乎像 && 运算符，但不完全一样：

当你使用x.a==1 && x.b==1where 子句翻译成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 语句。