c# - LINQ 为简单订单生成子查询

Question

我无法理解为什么 SQL 输出有一个我在 LINQ 中编写的简单查询的子查询。这是我的代码:

var list = db.User.Where(u => u.Name == somename).OrderBy(u => u.IdUser).ToList();

其中 somename 是我在执行时传递的参数。

输出的 SQL 是:

SELECT
Project1.IdUser, 
Project1.Name
FROM (SELECT
Extent1.IdUser, 
Extent1.Name
FROM user AS Extent1
WHERE Extent1.Name = 'John' /* @p__linq__0 */) AS Project1
ORDER BY 
Project1.IdUser ASC

对于这么简单的东西，输出真的应该有一个子查询吗？

我也试过

var list = db.User.Where(u => u.Name.Equals(somename)).OrderBy(u => u.IdUser).ToList();

生成与上面相同的输出。

如果我对参数进行硬编码，例如:

var list = db.User.Where(u => u.Name == "John").OrderBy(u => u.IdUser).ToList();

它按预期工作，只生成

SELECT
Extent1.IdUser, 
Extent1.Name
FROM user AS Extent1
WHERE 'John' /* @gp1 */ = Extent1.Name
ORDER BY 
Extent1.IdUser ASC

我正在使用的一些东西:

• Entity Framework 5、.NET 4.5
• SQL Server 2012
• Glimpse(使用 MiniProfiler)查看生成的 SQL

我不是 LINQ 专家，所以我在这里缺少什么？

Answer 1

正如其他人所指出的，查询结果与您的执行计划相同。 Entity Framework(和 LINQ to Entites)可帮助您避免编写 SQL 和为 SQL 烦恼(在某种程度上)。在正常情况下，您不关心生成的 SQL，也不“调试”它。您只关心 LINQ 查询是否正确。 Entity Framework (应该)将其转换为正确的(有时甚至是预期的)SQL(同样，执行计划很重要)。

我并不是说您不应该出于性能原因(或者更确切地说是该查询的执行计划)考虑 SQL。但这应该在您确定性能问题后完成。并且您应该首先尝试编写简单 查询，这才是成功之道。当然，如果你了解 SQL，你就会知道这个集合世界不同于对象世界——你可以在 LINQ 中轻松编写相当普通的查询(多亏了对象世界)，但这最终会成为讨厌的 SQL(集合世界)，因为“世界之间的“不匹配”。