有两个选项可用于处理使用 SQL 填充的 LINQ to Collections(我使用的是 Oracle 提供程序，因此没有 ORM 就没有 LINQ)。
执行一个大型 SQL 查询，将结果转储到某种集合中，然后对集合执行 LINQ 查询，这样您就可以对数据库进行一次大的调用，但此后不会有太大的减慢。
执行小型 SQL 查询并将结果转储到许多较小的集合中，然后对这些集合执行 LINQ 查询，这样您对数据库的消耗就会更小，但整个应用程序的速度会更加一致。
有人对此有什么想法吗？
最佳答案
这两种方法有一个很大的区别:如果每次需要数据时都去查询数据库，就会得到最新的数据，而如果一次性读入所有数据并重复使用，则不会得到最新的数据。查看最新的更改，直到您再次阅读所有内容。两种系统都有优点和缺点，但您需要意识到这种差异。
关于性能差异 - 不要假设本地数据上的 LINQ to Objects 总是比数据库查询更快。数据库针对不同类型的查询进行了令人难以置信的优化，并且可以利用索引。 LINQ to Object 查询通常只是迭代整个数据集。因此，即使您在本地拥有数据，除非您自己努力对数据建立索引，但某些查询实际上可能比您让数据库来完成工作要慢。
即使对于无法使用索引的查询，数据库仍然可以击败简单的 LINQ to Objects 方法。数据库有一些非常先进的算法，这些算法未在 LINQ to Objects 中实现。例如，常见的查询是使用过滤器获取按某些条件排序的前 100 个项目。即使没有足够大的结果集的可用索引，数据库的性能仍可能优于 LINQ to Objects，因为 OrderBy(x => x.Foo).Take(100) 将首先执行 O(n log n )排序，然后取出前一百个元素并丢弃其余的。 SQL Server 团队知道这种类型的查询很常见，因此他们添加了一个特殊的优化调用 TOP N SORT它可以在 O(n) 时间内执行此操作。我想Oracle也有类似的优化。我写过another answer其中详细介绍了这一点，包括 LINQ to SQL 与 LINQ to Objects 查询的一些性能测量。
关于.net - LINQ to SQL/LINQ to Collections 性能，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3375780/