更新 3:根据 this announcement ，这已由 EF 团队在 EF6 alpha 2 中解决。

更新 2:我提出了解决此问题的建议。投票给它，go here .

考虑一个带有一个非常简单的表的 SQL 数据库。

CREATE TABLE Main (Id INT PRIMARY KEY)

我用 10,000 条记录填充表。

WITH Numbers AS
(
  SELECT 1 AS Id
  UNION ALL
  SELECT Id + 1 AS Id FROM Numbers WHERE Id <= 10000
)
INSERT Main (Id)
SELECT Id FROM Numbers
OPTION (MAXRECURSION 0)

我为表构建了一个 EF 模型并在 LINQPad 中运行以下查询(我使用的是“C# 语句”模式，因此 LINQPad 不会自动创建转储)。

var rows = 
  Main
  .ToArray();

执行时间约为 0.07 秒。现在我添加 Contains 运算符并重新运行查询。

var ids = Main.Select(a => a.Id).ToArray();
var rows = 
  Main
  .Where (a => ids.Contains(a.Id))
  .ToArray();

这个案例的执行时间是20.14 秒(慢了 288 倍)!

起初我怀疑为查询发出的 T-SQL 执行时间较长，因此我尝试将其从 LINQPad 的 SQL Pane 剪切并粘贴到 SQL Server Management Studio 中。

SET NOCOUNT ON
SET STATISTICS TIME ON
SELECT 
[Extent1].[Id] AS [Id]
FROM [dbo].[Primary] AS [Extent1]
WHERE [Extent1].[Id] IN (1,2,3,4,5,6,7,8,...

结果是

SQL Server Execution Times:
  CPU time = 0 ms,  elapsed time = 88 ms.

接下来我怀疑是 LINQPad 导致了问题，但无论我在 LINQPad 还是在控制台应用程序中运行它，性能都是一样的。

因此，问题似乎出在 Entity Framework 的某个地方。

我是不是做错了什么？这是我代码中的时间关键部分，我可以做些什么来提高性能吗？

我正在使用 Entity Framework 4.1 和 Sql Server 2008 R2。

更新 1:

在下面的讨论中，有一些问题是关于延迟是在 EF 构建初始查询时还是在解析收到的数据时发生的。为了对此进行测试，我运行了以下代码，

var ids = Main.Select(a => a.Id).ToArray();
var rows = 
  (ObjectQuery<MainRow>)
  Main
  .Where (a => ids.Contains(a.Id));
var sql = rows.ToTraceString();

这会强制 EF 生成查询而不对数据库执行查询。结果是此代码需要约 20 秒才能运行，因此看起来几乎所有时间都花在了构建初始查询上。

那么 CompiledQuery 可以拯救吗？没那么快……CompiledQuery 要求传递给查询的参数是基本类型(int、string、float 等)。它不接受数组或 IEnumerable，因此我不能将它用于 ID 列表。

最佳答案

更新:通过在 EF6 中添加 InExpression，处理 Enumerable.Contains 的性能显着提高。不再需要此答案中描述的方法。

您是对的，大部分时间都花在处理查询的翻译上。 EF 的提供程序模型当前不包含表示 IN 子句的表达式，因此 ADO.NET 提供程序本身不能支持 IN。相反，Enumerable.Contains 的实现将其转换为 OR 表达式树，即 C# 中的内容如下所示:

new []{1, 2, 3, 4}.Contains(i)

...我们将生成一个可以表示如下的 DbExpression 树:

((1 = @i) OR (2 = @i)) OR ((3 = @i) OR (4 = @i))

(表达式树必须平衡，因为如果我们将所有 OR 都放在一个长脊柱上，表达式访问者将更有可能遇到堆栈溢出(是的，我们在测试中确实遇到了))

我们稍后将这样的树发送给 ADO.NET 提供程序，它可以识别此模式并在 SQL 生成期间将其缩减为 IN 子句。

当我们在 EF4 中添加对 Enumerable.Contains 的支持时，我们认为无需在提供程序模型中引入对 IN 表达式的支持就可以做到这一点，老实说，10,000 比我们预期的客户元素数量要多得多将传递给 Enumerable.Contains。也就是说，我知道这很烦人，而且在您的特定场景中，表达式树的操作会使事情变得过于昂贵。

我与我们的一位开发人员讨论了这个问题，我们相信将来我们可以通过添加对 IN 的一流支持来更改实现。我会确保将其添加到我们的积压工作中，但我无法保证何时会完成，因为我们还想进行许多其他改进。

对于线程中已经建议的解决方法，我将添加以下内容:

考虑创建一个方法来平衡数据库往返次数与您传递给 Contains 的元素数量。例如，在我自己的测试中，我观察到针对 SQL Server 的本地实例计算和执行具有 100 个元素的查询需要 1/60 秒。如果您可以这样编写查询，即使用 100 个不同的 id 集执行 100 个查询将得到与具有 10,000 个元素的查询相同的结果，那么您可以在大约 1.67 秒而不是 18 秒内获得结果。

不同的 block 大小应该根据查询和数据库连接的延迟更好地工作。对于某些查询，即如果传递的序列有重复项，或者如果在嵌套条件下使用 Enumerable.Contains，您可能会在结果中获得重复的元素。

这是一个代码片段(抱歉，如果用于将输入分割成 block 的代码看起来有点过于复杂。有更简单的方法可以实现同样的事情，但我试图想出一个模式来保留流序列，我在 LINQ 中找不到类似的东西，所以我可能做得太过火了 :) ):

用法:

var list = context.GetMainItems(ids).ToList();

上下文或存储库的方法:

public partial class ContainsTestEntities
{
    public IEnumerable<Main> GetMainItems(IEnumerable<int> ids, int chunkSize = 100)
    {
        foreach (var chunk in ids.Chunk(chunkSize))
        {
            var q = this.MainItems.Where(a => chunk.Contains(a.Id));
            foreach (var item in q)
            {
                yield return item;
            }
        }
    }
}

切片可枚举序列的扩展方法:

public static class EnumerableSlicing
{

    private class Status
    {
        public bool EndOfSequence;
    }

    private static IEnumerable<T> TakeOnEnumerator<T>(IEnumerator<T> enumerator, int count, 
        Status status)
    {
        while (--count > 0 && (enumerator.MoveNext() || !(status.EndOfSequence = true)))
        {
            yield return enumerator.Current;
        }
    }

    public static IEnumerable<IEnumerable<T>> Chunk<T>(this IEnumerable<T> items, int chunkSize)
    {
        if (chunkSize < 1)
        {
            throw new ArgumentException("Chunks should not be smaller than 1 element");
        }
        var status = new Status { EndOfSequence = false };
        using (var enumerator = items.GetEnumerator())
        {
            while (!status.EndOfSequence)
            {
                yield return TakeOnEnumerator(enumerator, chunkSize, status);
            }
        }
    }
}

希望这对您有所帮助!

关于c# - 为什么 Contains() 运算符会如此显着地降低 Entity Framework 的性能？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/7897630/