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提供程序进行选择时，您将调用一个特殊的存储过程，其中第一个参数是您的查询文本。然后执行计划仍然被缓存。

如果您的商店中有超过1个选择，则存储的数据会更好。

Answer 5

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

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

Linq查询仅在必须的最后一分钟进行评估。因此，您可以在评估之前为查询添加“where”限制。整个表达式，包括过滤器，将在数据库上执行，应该如此。

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

有些人会提倡存储过程通过SQL或ORMS访问您的数据库。这在其他问题上一直存在争议。例如here和here

我的观点是，对于某些事情，你需要一个专业的DBA来制作一个最佳的存储过程。然后，如果需要，您可以从Linq访问它。但是80％或更多的数据库访问方法不会对性能至关重要，而存储过程可能会耗费大量时间。

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

Answer 6

值得记住的是，LINQ to SQL首先从数据库中检索对象，然后将属性更改应用于对象，并调用SubmitChanges将其保留，然后每个行/对象发出必要的更新语句。

对于批量更新，这远远不如发送一次适用于整批行的单个更新语句那么高效。

Answer 7

通常，对许多记录的操作应该尽可能接近db。如果它是我的任务我将在存储过程中执行它。我个人而言。 Linq是数据访问的另一层抽象，虽然它适用于“正常”需求，即发送到UI的几百个实体，但它不应被视为数据仓库类型操作的替代品。