在我的日常生活中，我写了大量的linq，但主要是简单的陈述。我已经注意到，使用where子句时，有许多种写法，据我所知每种方法都有相同的结果。例如;
from x in Collection
where x.Age == 10
where x.Name == "Fido"
where x.Fat == true
select x;至少就结果而言似乎与之等效：
from x in Collection
where x.Age == 10 &&
x.Name == "Fido" &&
x.Fat == true
select x;那么，除了语法以外，真的有区别吗？如果是这样，首选样式是什么，为什么？
Answers:
第二个会更高效，因为它只有一个谓词可以对集合中的每个项目进行评估，与第一个一样，它将第一个谓词首先应用于所有项目，结果（此时缩小了范围）是用于第二个谓词，依此类推。每次通过都会缩小结果范围，但仍然涉及多次通过。
同样，仅当您对谓词进行“与”运算时，链接（第一种方法）才有效。这样的事情x.Age == 10 || x.Fat == true不适用于您的第一种方法。
编辑：对象的LINQ行为不符合我的预期。您可能对我刚刚写的博客文章感兴趣...
它们在称为什么方面有所不同-第一个等效于：
Collection.Where(x => x.Age == 10)
.Where(x => x.Name == "Fido")
.Where(x => x.Fat == true)后者等同于：
Collection.Where(x => x.Age == 10 &&
x.Name == "Fido" &&
x.Fat == true)现在，实际产生的差异取决于Where调用的实现。如果它是一个基于SQL的提供程序，我希望两者最终会创建相同的SQL。如果它在LINQ to Objects中，则第二个将具有较少的间接级别（仅涉及两个迭代器，而不是四个）。这些间接级别在速度方面是否很重要是另一回事。
通常，我会使用多个where子句，如果它们感觉它们代表着截然不同的条件（例如，一个与一个对象的一部分有关，而一个则是完全独立的），而where当各种条件密切相关（例如，一个特定值）时，则使用一个子句大于最小值且小于最大值）。基本上，在任何轻微的性能差异之前，都值得考虑可读性。
第一个将被实施：
Collection.Where(x => x.Age == 10)
.Where(x => x.Name == "Fido") // applied to the result of the previous
.Where(x => x.Fat == true) // applied to the result of the previous相对于更简单的（和远快可能更快）：
// all in one fell swoop
Collection.Where(x => x.Age == 10 && x.Name == "Fido" && x.Fat == true)当我跑步
from c in Customers
where c.CustomerID == 1
where c.CustomerID == 2
where c.CustomerID == 3
select c和
from c in Customers
where c.CustomerID == 1 &&
c.CustomerID == 2 &&
c.CustomerID == 3
select c customer table in linqpad针对我的客户表，它输出相同的SQL查询
-- Region Parameters
DECLARE @p0 Int = 1
DECLARE @p1 Int = 2
DECLARE @p2 Int = 3
-- EndRegion
SELECT [t0].[CustomerID], [t0].[CustomerName]
FROM [Customers] AS [t0]
WHERE ([t0].[CustomerID] = @p0) AND ([t0].[CustomerID] = @p1) AND ([t0].[CustomerID] = @p2)所以在翻译成sql时没有区别，您已经在其他答案中看到了它们将如何转换为lambda表达式
Fat属性？这很简单。