实体，处理大量记录（> 3500 万条）

我们有一组相当大的相关表，每个表有超过 3500 万条相关记录。我需要创建几个 WCF 方法，它们使用一些参数（数据范围、类型代码等）查询数据库并返回相关结果集（从 10 到 10,000 条记录）。

该公司采用 EF 4.0 进行标准化，但对 4.X 持开放态度。我也许可以提出迁移到 5.0 的论点，但可能性较小。

使用实体处理如此大量记录的最佳方法是什么？我应该创建一组存储过程并从实体中调用它们还是我可以在实体中执行某些操作？

我对数据库没有任何控制权，因此无法拆分表或创建一些物化视图或分区表。

非常感谢任何意见/想法/建议。

在我的工作中，我也遇到过类似的情况。我们有一个包含许多表的数据库，其中大多数每个表包含大约 7-1000 万条记录。我们使用Entity框架来显示数据，但页面似乎显示很慢（比如90到100秒）。甚至网格上的排序也需要时间。我接到的任务是看看它是否可以优化。在对它进行分析（ANTS分析器）之后，我能够对其进行优化（7秒以下）。

所以答案是是的，实体框架可以处理大量记录（以百万计），但必须小心

1. 了解仅在需要实际记录时才调用数据库。所有操作都只是用于进行查询（SQL），因此请尝试仅获取一条数据，而不是请求大量记录。尽可能修剪获取大小
2. 是的，不应该，您必须使用存储过程并将它们导入到您的模型中，并为它们导入函数。您也可以直接调用它们 ExecuteStoreCommand()、ExecuteStoreQuery()。函数和视图也是如此，但 EF 有一种非常奇怪的调用函数“SELECT dbo.blah(@id)”的方式。
3. 当 EF 必须填充具有深层层次结构的实体时，EF 的执行速度会变慢。对于具有深层层次结构的实体要格外小心。
4. 有时，当您请求记录并且不需要修改它们时，您应该告诉 EF 不要监视属性更改 (AutoDetectChanges)。这样记录检索会快得多
5. 数据库索引很好，但对于 EF 来说它变得非常重要。用于检索和排序的列应该正确建立索引。
6. 当你的模型很大时，VS2010/VS2012模型设计师会变得非常疯狂。因此，将您的模型分解为中型模型。存在一个限制，即来自不同模型的实体无法共享，即使它们可能指向数据库中的同一个表。
7. 当您必须在不同位置对同一实体进行更改时，请尝试通过传递该实体来使用同一实体并仅发送一次更改，而不是每次都获取一个新的部分，进行更改并存储它（真正的性能增益技巧）。
8. 当您仅需要一列或两列中的信息时，请尽量不要获取完整的实体。你可以直接执行你的sql或者有一个迷你实体。您可能还需要在应用程序中缓存一些常用的数据。
9. 交易缓慢。小心他们。

如果您记住这些事情，EF 应该提供与普通 ADO.NET 几乎相似的性能（如果不一样的话）。