.net - LINQ 有多快？

Question

我需要处理 100,000 - 200,000 条记录。
我正在考虑使用 LINQ (to SQL) 来做到这一点。
我从经验中知道过滤数据视图非常慢。
那么LINQ有多快呢？

您能否告诉我您的经验以及它是否值得使用，或者我最好使用 SQL 存储过程（繁重且不太灵活）？

在数千条记录中，我需要找到数据组然后对其进行处理，每组大约有 50 条记录。

Answer 1

LINQ to SQL 将您的查询表达式转换为 T-SQL，因此您的查询性能应该与通过 ADO.NET 发送该 SQL 查询完全相同。我猜有一点开销，将查询的表达式树转换为等效的 T-SQL，但我的经验是，与实际查询时间相比，这很小。

您当然可以准确地找出生成的 T-SQL，因此请确保您有良好的支持索引。

与 DataViews 的主要区别在于 LINQ to SQL 不会将所有数据放入内存并在那里过滤。相反，它让数据库做它擅长的事情，并且只将匹配的数据带入内存。

Answer 2

这取决于你想要做什么。LINQ 对我来说从数据库中提取数据的速度非常快，但是 LINQ-to-SQL 确实直接将您的请求转换为 SQL 来运行它。但是，有时我发现在某些情况下使用存储过程会更好。

例如，我有一些需要查询的数据，其中涉及多个表和相当密集的键。使用 LINQ，以及 LINQ 相对不灵活的自定义查询，这些查询将需要几分钟时间。通过手动调整 SQL（即，通过在 JOIN 中放置“WHERE”类型的参数以最小化 JOIN 的数据强度），我能够显着提高性能。

我的建议是，尽可能使用 LINQ，但如果您确定 LINQ 生成的 SQL 太慢，请不要害怕走存储过程路线，并且可以轻松地手动调整 SQL 以完成您需要的操作。

Answer 3

您需要更具体地说明操纵记录的含义。如果每条记录的更改不是 100% 单独的，并且可以基于集合进行更改，那么您很可能最好在数据库端（存储的过程）中在 T-SQL 中进行更改。换句话说，尽可能避免通过网络和/或进程边界提取大量数据。

Answer 4

我发现 LINQ 生成的查询很好。在 linq 查询中实现了一些最佳实践，例如我们，来自所有者的前缀表名，避免 (*) 等等。当查询很复杂（不仅仅是简单的连接）时，我发现 linq 总能找到一个好的解决方案，而我的解决方案从来没有更好（所以我的 SQL 分析器说）。

那么问题是：直接查询更好......还是将查询包装到存储过程中？存储过程应该更好，因为存储了执行计划。但实际上，当您通过 .net sql server provider 进行选择时，您调用了一个特殊的存储过程，其中第一个参数是您的查询文本。然后无论如何都会缓存执行计划。

如果在您的商店中您进行了超过 1 种选择，则存储的 shuold 会更好。

Answer 5

一段绳子有多长？LInq to SQL 的速度有多快。这取决于你如何使用它。

“过滤数据视图非常慢”，因为在此模型中您检索所有记录，然后在客户端进行过滤。但是 Linq to SQL 不能那样工作，除非你滥用它。

一个 Linq 查询只在它必须的最后一分钟被评估。因此，您可以在评估之前对查询添加“位置”限制。整个表达式，包括过滤器，将按原样在数据库上执行。

Stackoverflow 使用的是 Linq，它不是一个小数据库。

有些人会提倡存储过程通过 SQL 或 ORMS 访问您的数据库。这已在其他问题中进行了辩论。例如这里和这里

我的观点是，对于某些事情，您需要专业的 DBA 来制作最佳的存储过程。然后，您可以根据需要从 Linq 访问它。但是 80% 或更多的数据库访问方法不会对性能至关重要，并且存储过程对于这些方法来说可能是非常耗时的。

对于更新，在存储过程或 sql 中使用“update ... where ...”的基于集合的服务器端操作将比使用多个数据库往返读取记录、写入记录、重复要快得多.

Answer 6

值得牢记的是，LINQ to SQL 首先从数据库中检索对象，然后将属性更改应用于对象并调用 SubmitChanges 将它们持久化，然后每个行/对象都会发出必要的更新语句。

对于批量更新，这远没有一次只发送一条适用于整批行的更新语句那么有效。

Answer 7

通常，对这么多记录的操作应该尽可能靠近数据库。如果它在我的任务中，我希望在存储过程中完成它。那是我个人。Linq 是数据访问之上的另一个抽象层，虽然它适用于“正常”需求，即发送到 UI 的数百个实体，但不应将其视为数据仓库类型操作的替代品。