实体，处理大量记录（> 3,500万）

Question

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

该公司在EF 4.0上进行了标准化，但对4.X开放。我也许可以说服自己移植到5.0，但可能性很小。

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

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

任何输入/想法/建议都将不胜感激。

Answer 1

在工作中，我遇到了类似的情况。我们有一个包含许多表的数据库，其中大多数表包含大约7到1千万条记录。我们使用实体框架来显示数据，但是页面似乎显示得非常慢（例如90到100秒）。甚至在网格上进行排序也需要时间。我得到了任务，看是否可以优化。并且在对它进行分析之后（ANTS探查器），我能够对其进行优化（不到7秒）。

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

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

如果您牢记这些内容，则EF应该提供与普通ADO.NET几乎相同的性能（如果不同）。

Answer 2

我对 EF4.1 的经验，代码优先：如果您只需要读取记录（即您不会将它们写回），您将通过针对您的上下文进行更改跟踪来获得性能提升：

yourDbContext.Configuration.AutoDetectChangesEnabled = false;

在加载任何实体之前执行此操作。如果您需要更新加载的记录，您可以随时致电

yourDbContext.ChangeTracker.DetectChanges();

在调用 SaveChanges() 之前。