列表很长的 LINQ/SQL 性能问题答案

【问题标题】：LINQ / SQL Performace problem with a very long list列表很长的 LINQ/SQL 性能问题
【发布时间】：2010-12-17 03:02:58
【问题描述】：

在我们的数据库中，我们有一个包含超过 100000 个条目的表，但大多数时候我们只需要其中的一部分。我们通过一个非常简单的查询来做到这一点。

items.AddRange(from i in this
    where i.ResultID == resultID && i.AgentID == parentAgentID
    orderby i.ChangeDate descending
    select i);

在这个查询之后，我们得到一个包含多达 500 个项目的列表。但即使从这个结果来看，我们也只需要最新的和以下的项目。我的同事通过以下方式非常简单地做到了这一点：

items[0];
items[1];

工作正常，因为查询结果已经按日期排序。但是整体表现很差。甚至需要几秒钟。

我的想法是在查询末尾添加一个 .Take(2) 但我的同事说这不会有任何区别。

items.AddRange((from i in resultlist
    where i.ResultID == resultID && i.AgentID == parentAgentID
    orderby i.ChangeDate descending
    select i).Take(2));

我们还没有尝试过，我们仍在寻找其他方法来加快速度。但数据库编程并不是我们的强项，任何建议都会很棒。

也许我们甚至可以对数据库本身进行一些调整？我们使用 SQL Compact 数据库。

【问题讨论】：

标签： sql linq performance

【解决方案1】：

1 - 添加索引以覆盖您在查询中使用的字段

2 - 确保不会因为过于频繁地重复查询而只获得前 2 名

尝试定义可让您获取一批记录的查询条件

3 - 尝试编译您的 LINQ 查询

【讨论】：

【解决方案2】：

您可能遇到的问题是数据被拉到您的计算机上，然后您正在对其执行 Take(2)。可能花费最多时间的部分是将所有这些数据提取到您的应用程序中。如果您希望 SQL Server 执行此操作，请确保在完成查询语句之前不要访问任何结果集记录的值。

其次，LINQ 对应用程序内存中的大量数据进行排序和 where 子句等操作并不快。有时在 LINQ 中编写要容易得多，但在数据库中执行尽可能多的排序和 where 子句总是比在内存对象集中进行操作要好。

如果您真的关心这种情况下的性能，请不要使用 LINQ。做个循环就好了。

http://ox.no/posts/linq-vs-loop-a-performance-test

我喜欢使用 LINQ-To-SQL 和 LINQ，但它并不总是适合这项工作的工具。如果您有大量数据并且性能很关键，那么您不想将 LINQ 用于内存排序和 where 语句。

【讨论】：

【解决方案3】：

添加 .Take(2) 会有很大的不同。如果您只需要两个项目，那么您绝对应该使用它，它肯定会为您带来性能差异。

添加它并查看从它生成的 SQL。生成的 SQL 只会得到 2 条记录，这将节省您在 SQL 端和对象实例化端的时间。

【讨论】：

【解决方案4】：

如果优化器相当聪明，尤其是在 ChangeDate 列被索引的情况下，使用Take(2) 确实应该有所作为。（我不知道 SQL Compact 版本做了多少优化，但我仍然希望限制结果会有所帮助。）

但是，您不应该相信我或其他任何人会这么说。查看每种情况下生成的查询，并针对 SQL 分析器运行它。看看执行计划是什么。用各种样品测量性能。测量，测量，测量。

【讨论】：