.net - Entity Framework - 第一次查询很慢

Question

正如标题所示，我在使用 Entity Framework 对 SQL Server 数据库进行第一次查询时遇到问题。

我曾尝试在不同的网站上寻找答案，但似乎没有人真正有解决方案。

我从数据库中加载了很多行，包括两个 0-many 关系。

测试是在 Visual Studio 2010 中使用 Entity Framework 4.0 模型和 POCO 生成器完成的(普通实体和 POCO 对象之间的时间没有太大差异)。我还使用了 T4 View 模板来预编译 View 。

该数据库位于 SQL Server 2008 上。

我真正想知道的是为什么第一个查询比任何次要查询都慢得多。

我还想知道是否可以采取措施将第一个查询的速度提高到可接受的范围内。

这是一个很大的查询，我们可能会得到其他更大的查询，可以理解的是，它们可能有点慢，但是 30 秒对于用户来说太慢了，无法等待，尤其是当数据集可以更快地获取相同数据时。

我做了一些计时测试来尝试找出问题所在，我有点惊讶地发现它看起来是 SQL Server 在第一次查询时很慢。

时间如下:

.NET 测试应用程序:

第一个查询:29,6 秒

第二个查询:3,2 秒

SQL探查器:

第一次查询:27 秒

第二个查询:3,2 秒

SQL Server 查询窗口

第一次查询:8 秒

第二次查询:4 秒

应用程序中的计时使用 Stopwatch 测量类(class)。只有查询被测量和 .ToList()用于执行查询。

SQL Server Profiler 中的计时针对在应用程序中执行的相同查询，这表明应用程序仅使用大约 2.6 秒将数据填充到对象中。

最后 27 秒用于在 SQL Server 上执行查询。

查看辅助查询，应用程序和 SQL 服务器的时间相同，但这次执行查询要快得多。

我可以理解为什么应用程序不使用任何时间，因为没有需要转换为对象的新行，但为什么查询速度如此之快，由于执行计划，我预计需要几秒钟而不是 24 秒。

仅出于测试目的，我复制了 Entity Framework 生成的 SQL，并使用单独的连接打开了一个新的查询窗口，并在其中执行了查询。

如您所见，第一个查询需要 8 秒，第二个查询需要 4 秒。

我希望有人有一些建议。

附:我为文字墙道歉:)

编辑 19-10-2010:
我昨天做了一个测试，似乎支持按顺序返回行。这意味着当一行从数据库返回时，它会立即被物化(如果它在上下文中尚不存在)然后返回下一行，依此类推。

这就是为什么查询在数据库服务器上花费了大量时间的原因，因为实现时间包含在 SQL Server 探查器计时中。

我不相信这是 SQL Server 从硬盘读取的情况。
每次在 EF 中出现“第一次查询”时，都会发生慢查询。

前任。

使用 EF 运行第一个查询，SQL 语句比任何辅助查询都慢

处置上下文/存储库

创建新上下文

运行与之前相同的查询(同样，第一个查询很慢，SQL 语句也是如此)

这几乎就像 EF 发送一些选项以及使服务器变慢的第一个查询。

至于查询编译，我记得查询是在第一次使用时编译的，这意味着第一个查询需要更长的时间来执行。

二级查询会更快，但二级查询的速度不是问题。

我还做了一个测试，我创建了一个编译查询作为静态，以便为所有创建的上下文编译它。

然后我创建了一个上下文，运行了查询，销毁了上下文并创建了一个新的上下文并再次运行相同的查询。

差异并不大，只有几秒钟，而我第一次运行查询时，它仍然需要与没有预编译一样长的时间。

至于 View 生成，我们已经使用 T4 模板实现了这一点。

答案真的是 EF 仅在您只执行仅返回相对少量数据的最简单查询之外什么都不做的情况下才有效吗？

Answer 1

我们在 EF 5.0 中遇到了同样的问题，截至今天，肤浅的 Google 搜索并未显示足够的加速。

根据此链接 http://msdn.microsoft.com/en-us/library/cc853327(v=vs.100).aspx “加载元数据”的时间成本适中，但每个 AppDomain 只需要发生一次。我没有发现像加载元数据的技巧之类的预编译。

我们实现的解决方法是在应用程序启动时在单独的线程中对 Context 进行次要查询。这加载元数据，它仍然需要很长时间(在我们的例子中为 18-19 秒)，但应用程序在加载过程中响应。此外，第一次实际加载不需要那么长时间。

请注意，在我们的上下文中，用户可能会在应用程序中花费 18-19 秒，然后才需要进行 EF 调用以响应他们的操作。显然，如果这在您的应用程序中是不可能的，那么这个解决方法可能不会提供太多的速度提升。