entity-framework-4 - 实体，处理大量记录(> 3,500万)

我们有大量的相关表，每个表有超过3500万个相关记录。我需要创建几个WCF方法，这些方法将使用一些参数(数据范围，类型代码等)查询数据库，并返回相关的结果集(从10到10,000条记录)。该公司在EF 4.0上进行了标准化，但对4.X开放。我也许可以说服自己移植到5.0，但可能性很小。使用Entity处理如此大量的记录的最佳方法是什么？我应该创建一组存储的proc并从Entity中调用它们，还是可以在Entity中执行某些操作？我对数据库没有任何控制权，因此无法拆分表或创建某些物化 View 或分区表。任何输入/想法/建议，我们将不胜感激。 最佳答案 在我的工作中，我遇到了类似的情况。我们有一个包含许多表的数据库，其中大多数表包含大约7到1千万条记录。我们使用 Entity Framework 来显示数据，但是页面似乎显示得非常慢(例如90到100秒)。甚至在网格上进行排序也需要时间。我得到了一项任务，看是否可以对其进行优化。并且在对它进行分析之后(ANTS profiler)，我能够对其进行优化(不到7秒)。所以答案是是的，Entity Framework可以处理记录负载(以百万计)，但是必须格外小心了解仅在需要实际记录时才对数据库进行的调用。所有操作仅用于进行查询(SQL)，因此请尝试仅获取一条数据，而不是请求大量记录。尽可能缩小获取大小是的，不是应该的，您必须使用存储过程并将其导入模型中，并为它们导入函数。您也可以直接调用它们ExecuteStoreCommand()，ExecuteStoreQuery ()。函数和 View 也一样，但是EF调用函数“SELECT dbo.blah(@id)”的方法确实很奇怪。 EF必须填充具有较深层次结构的实体时，其执行速度较慢。对具有较高层次的实体极为小心。 有时，当您请求记录且不需要修改它们时，应告诉EF不要监视属性更改(AutoDetectChanges)。这样，记录检索就更快了数据库索引很好，但是在EF的情况下，它变得非常重要。用于检索和排序的列应正确索引。 当您的模型很大时，VS2010/VS2012模型设计器会变得非常疯狂。因此将您的模型分成中等大小的模型。存在一个局限性，即使它们可能指向数据库中的同一表，也无法共享来自不同模型的实体。 当您必须在不同位置的同一实体中进行更改时，请尝试通过传递相同的实体并仅发送一次更改，而不是每一次都获取一个新的更改，进行更改并存储(实际性能提高技巧) 。 当您只需要一两列信息时，请尽量不要获取完整的实体。您可以直接执行sql，也可以拥有迷你实体。您可能还需要在应用程序中缓存一些经常使用的数据。 事务很慢。小心他们。 如果您牢记这些内容，那么EF应该会提供与普通ADO.NET几乎相同的性能(如果不同的话)。关于entity-framework-4 - 实体，处理大量记录(> 3,500万)，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/14205033/