由于视图重新计算，LinQ 查询的持续时间很长答案

【问题标题】：LinQ query has long duration because of View recalculation由于视图重新计算，LinQ 查询的持续时间很长
【发布时间】：2010-09-22 18:21:06
【问题描述】：

我已经在数据库中创建了一个视图，它为我提供了一个组织结构在这个时间点的表示。事实上，我在这个视图中使用了 getdate()。我已经在我的 edmx 中导入了该视图，并根据该视图编写了查询。大多数查询将表与视图连接起来并返回 DTO。当我在 SQL 分析器中对它们进行分析时，这些查询工作正常并且速度很快（200 毫秒）。

当我对连接的表和视图进行分组时，持续时间要长得多。奇怪的是，当我执行 LinQ 查询时，持续时间很长，但是当我自己在 SQL Server Management Studio 中执行生成的查询时，它真的很快。我已经确定这不是由已经计算过的缓存或执行计划引起的。 LinQ 查询也给了我很多读取和写入，而通过 SQL Mgmt Studio 的查询给我没有写入和更少的读取。

我们假设在通过 LinQ 执行查询而不是通过 SQL Mgmt Studio 执行查询时需要重新计算视图。

我尝试过的另一种方法是在数据库中创建一个存储过程。此存储过程执行与 LinQ 生成的查询完全相同的查询。我已经在 edmx 中映射了这个存储的过程。当我再次通过 LinQ 调用存储过程时，持续时间很长（7000 毫秒）并且有很多读写操作。当我通过 SQL Mgmt Studio 执行它时，持续时间与预期一致（200 毫秒）并且读取很少，没有写入。

有什么建议吗？谢谢

【问题讨论】：

您必须向任何人提供更多信息才能对此发表任何看法。例如：视图看起来如何？您的 LINQ 查询看起来如何？执行的 SQL 是怎样的？

标签： linq performance view entity-framework-4

【解决方案1】：

听起来 Management Studio 正在执行某种 LINQ 无法执行的查询计划优化，因为它执行一系列单独的命令。

我的建议是尝试将一组合理的记录带入内存并在那里进行连接。这很容易做到。

假设你有这个查询：

var pcs =
    from p in dc.People
    join c in dc.Colors on p.FavColor equals c.Name
    where p.Name == "James"
    select new { p.Name, c.ColorId };

这会生成一系列对 SQL 的查询，这可能会导致您遇到的延迟类型。

所以试试这个吧：

var pcs =
    from p in dc.People.Where(x => x.Name == "James").ToArray()
    join c in dc.Colors.ToArray() on p.FavColor equals c.Name
    select new { p.Name, c.ColorId };

这应该会将查询减少到一两个，并且速度会快得多。您只需要确保这不会尝试将半百万条记录加载到内存中。如果发生这种情况，您的性能问题将从数据库转移到内存。

我希望这会有所帮助。

【讨论】：