我需要处理100,000 200,000条记录。
我正在考虑使用LINQ(到SQL)来做到这一点。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。
我从经验中知道，过滤数据视图非常慢。
LINQ有多快？
能否请我们告诉我经验以及是否值得使用，或者使用SQL存储过程(繁琐而又不太灵活)会更好吗？
在成千上万的记录中，我需要找到一组数据，然后对其进行处理，每组大约有50条记录。

解决方案

通常，对许多记录的操作应尽可能接近数据库。如果它在我的任务中，我会希望在存储过程中做到这一点。那是我个人。 Linq是数据访问之上的又一个抽象层，尽管它可以很好地满足"正常"需求，即将数百个实体发送到UI，但不应将其视为数据仓库类型操作的替代品。

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

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

与DataViews的主要区别在于LINQ to SQL不会将所有数据带入内存并在那里进行过滤。而是使数据库执行其擅长的工作，并且仅将匹配的数据带入内存。

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

例如，我有一些需要查询的数据，其中涉及多个表和相当密集的键。使用LINQ以及LINQ相对不灵活的自定义查询，这些查询将花费几分钟。通过手动调整SQL(即，通过在JOIN中放置" WHERE"类型的参数以最大程度地降低JOIN的数据强度)，我能够极大地提高性能。

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

我们需要对操作记录的含义进行更具体的说明。如果每个记录的更改不是100％个别的，并且可以基于集合进行更改，则我们最好在db端在T-SQL中进行更改(存储的proc)。换句话说，如果可能，请避免通过网络和/或者进程边界提取大量数据。

一段绳子有多长？ LInq到SQL有多快。这取决于我们如何使用它。

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

仅在可能的最后分钟才评估Linq查询。因此，我们可以在对查询进行评估之前为其添加" where"限制。整个表达式(包括过滤器)将按原样在数据库上执行。

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

有些人会提倡使用存储过程来通过SQL或者ORMS访问数据库。在其他问题上对此进行了辩论。例如在这里和这里

我的观点是，对于某些事情，我们将需要专业的DBA来设计最佳的存储过程。然后，我们可以根据需要从Linq访问此文件。但是80％或者更多的数据库访问方法对性能不是至关重要的，而存储的proc对于这些方法可能是费时的过大杀伤力。

对于更新，在存储的proc或者sql中使用" update ... where ..."进行基于集合的服务器端操作比使用多个数据库往返读取记录，写入记录，重复执行要快得多。 。

我发现LINQ生成的查询很好。在linq查询中实现了一些最佳实践，例如我们，所有者的前缀表名，避免(*)等。当查询很复杂(不仅仅是简单的联接)时，我发现linq总是找到一个好的解决方案，而我的解决方案再也没有比这更好的了(所以我的SQL事件探查器说)。

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

如果在商店中进行了1次以上选择，则存储的shuold会更好。

值得记住的是，LINQ to SQL的工作方式是首先从数据库中检索对象，然后将属性更改应用于对象，然后调用SubmitChanges将其持久化，从而使每行/对象都发出必要的更新语句。

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