具有很长列表的LINQ/SQL性能问题

在我们的数据库中，我们有一个超过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数据库。

使用

Take（2）

确实应该有所不同，如果优化人员相当聪明，尤其是如果对ChangeDate列进行了索引。（我不知道SQL Compact edition做了多少优化，但我仍然希望限制结果会有所帮助。）

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

添加.Take（2）将产生很大的不同。如果你只需要两个项目，那么你一定要使用它，它肯定会对你的性能产生影响

---

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

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

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

如果您真的关心此场景中的性能，请不要使用LINQ。绕个圈就行了

---

我喜欢使用LINQtoSQL和LINQ，但它并不总是适合这项工作的工具。如果您有大量数据，并且性能至关重要，那么您就不希望使用LINQ进行内存内排序和where语句。

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

2-确保通过过于频繁地重复查询不会导致仅获得前2名

• 尝试定义查询条件，以便获取一批记录

3-尝试编译LINQ查询