.net - LINQ to SQL/LINQ to Collections 性能

Question

处理用 SQL 填充的 LINQ to Collections 有两种选择(我使用的是 Oracle 提供程序，因此没有 ORM 就没有 LINQ)。

做一个大的 SQL 查询，将结果转储到某种集合中，然后对集合进行 LINQ 查询，这样你就可以对数据库进行一次大的绘制，但之后不会有太大的减速。

执行小型 SQL 查询并将结果转储到许多较小的集合中，然后对这些集合进行 LINQ 查询，这样您对数据库的占用较小，但整个应用程序的速度会更加一致。

有没有人对此有任何想法？

Answer 1

这两种方法有一个很大的区别:如果每次需要数据时都查询数据库，您将获得最新的数据，而如果一口气读入所有数据并重复使用，则您将看不到最新的数据更改，直到您再次阅读所有内容。两种系统都有优点和缺点，但您需要了解这种差异。

关于性能差异 - 不要假设本地数据上的 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) 时间内执行此操作。我想甲骨文也有类似的优化。我写了 another answer这将详细介绍这一点，包括 LINQ to SQL 与 LINQ to Objects 查询的一些性能测量。