LINQ to SQL / LINQ to Collections 性能

Posted 2023-03-28

【中文标题】LINQ to SQL / LINQ to Collections 性能

【英文标题】：LINQ to SQL / LINQ to Collections Performance

【发布时间】：2010-07-30 22:18:22

【问题描述】：

有两个选项可用于处理填充了 SQL 的 LINQ to Collections（我使用的是 Oracle 提供程序，因此没有 ORM 就没有 LINQ）。

执行一次大型 SQL 查询，将结果转储到某种集合中，然后对集合执行 LINQ 查询，这样您就可以对数据库进行一次很大的利用，但之后不会减慢多少。

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

有人对此有什么想法吗？

【参考方案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 查询的一些性能测量。

【讨论】：

很公平，但是假设数据库以这种方式优化真的是个好主意吗？