我可以避免一个简单的Linq to Entities投影的嵌套SQL查询吗？

给出一个简单的LINQ到EF（EF5）声明：我可以避免一个简单的Linq to Entities投影的嵌套SQL查询吗？

MyDBSet.Select(x => x.Column1)

下面的SQL将制作：

SELECT 
[c].[Column1] AS [Column1] 
FROM (SELECT 
[MyDBSet].[Column1] AS [Column1], 
[MyDBSet].[Column2] AS [Column2], 
... 
[MyDBSet].[ColumnN] AS [ColumnN] 
FROM [dbo].[MyDBSet] as [MyDBSet]) as [c]

这将返回所有列额外的嵌套查询实际上是不必要的。这可能是无害的，但我认为我遇到的问题是如何扩展到相当复杂的查询中。所以：有没有这种额外的嵌套查询让EF生成SQL的方法？我的linq语句是用表达式树生成的，所以我想避免使用任何传递SQL。

来源

2014-10-31 skeej

为什么你需要？优化代码不是查询提供者的工作。数据库应该没有优化该查询的问题。 – Servy 2014-10-31 16:22:10

查看DBContext API中懒惰，渴望和显式加载作为在EF中创建SQL查询的不同方式。 – 2014-10-31 16:25:08

@Servy，你不能假定数据库会优化查询。我想他想创建更复杂的查询。 SQL是一种奇怪的生物 - 有时它会进行优化，而其他时候这种小的变化会影响性能。 – 2014-10-31 17:12:53

为Chris Hermut提到的，延迟加载查询：

IQueryable<ColumnType> query = context.MyDBSet.Select(X => X.Column1); 

IEnumerable<ColumnType> result = query.ToList();

来源

2014-10-31 17:12:07 InCommand

不幸的是，使用懒惰的方法似乎并没有改变生成的SQL。 – skeej 2014-10-31 17:23:54

linq genrates sql quereies like this – 2014-10-31 17:27:36

奇怪。

我只是想在一个测试数据库中LinqPad如下：

Contacts.Select(x => x.Email)

这里曾是SQL输出：

SELECT [t0].[email] 
FROM [contacts] AS [t0]

所以你是正确的 - 这是在你的背景是造成这选择所有的列，然后项目为column1。这似乎是在此线程的OP有同样的问题，这个回答表明，以优化的方式之一：

https://stackoverflow.com/a/13258796/201648

这不是最干净的解决方案，但它一定会为您提供了个SQL更精细的控制。同一线程中的另一个答案为EF提供了一些原因：

为什么实体框架会生成嵌套查询？简单的答案是，因为Entity Framework将您的查询表达式分解为表达式树，然后使用该表达式树构建您的查询。树自然生成嵌套查询表达式（即子节点生成查询，父节点生成查询查询）。

https://stackoverflow.com/a/13258313/201648

这是一个在黑暗中拍摄，但你有没有试图通过上下文的每个级别步进使用F10和F11来电，来看看是在每个点产生？我很好奇子查询是否在堆栈的早期生成，因为某些子选择在堆栈中不太明显。另外，MyDBSet.Select(x => x)产生了什么？

来源

2014-11-02 03:55:58

thanks-这很有用。我会深入研究，看看我找到了什么。 =） – skeej 2014-11-03 15:37:53

我可以避免一个简单的Linq to Entities投影的嵌套SQL查询吗？

回答

相关问题