LINQ生成子查询的简单顺序

时间:2013-10-05 20:49:33

标签: c# sql sql-server entity-framework

我无法理解为什么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

我正在使用的一些东西:

  • EntityFramework 5,.NET 4.5
  • SQL Server 2012
  • Glimpse(使用MiniProfiler)查看生成的SQL

我不是LINQ专家,所以我在这里缺少什么?

1 个答案:

答案 0 :(得分:1)

正如其他人指出的那样,查询会产生与您相同的执行计划。实体框架(和LINQ to Entites)可以帮助您避免编写SQL并在某种程度上打扰SQL。在正常情况下,您不关心生成SQL也不关心它“调试”它。你只关心LINQ查询是否正确。实体框架(应该)将其转换为正确的(有时甚至是预期的)SQL(并且执行计划也很重要)。

我并不是说你出于性能原因不应该看SQL(或者更好地说出该查询的执行计划)。但是, 之后你应该确定性能问题。你应该首先尝试编写 simple 查询,这是成功的方法。当然,如果你知道SQL,你知道这个集合的世界与对象世界不同 - 你可以在LINQ中轻松编写相当普通的查询(感谢对象世界),但这最终会因为“令人讨厌的SQL(设置世界)而因为”世界之间的不匹配。