DBContext SaveChanges 的内部工作原理是什么？

Question

使用Entity Framework和SQL Server 2008，我们有一个应用程序写入大量数据，例如每分钟1000个新行，每个都在自己的DBContext.saveChanges调用中（我们没有将它们批处理在一起）。

问题是我们的写入非常落后。到了似乎像是折磨的程度。例如，我们会在两分钟内多次使用saveChanges保存新行，但不会进行任何写入，然后突然间我们会得到一些写入（但很多都完全丢失）。

我们已经进行了SQL跟踪，并发现SQL甚至没有接收到写入命令的10%。

因此，在saveChanges和SQL Server之间似乎存在某个问题。我想知道这个调用是如何工作的。它使用线程池吗？排队？我们可能正在超出的某个缓冲区？也许由于写入的数量而默默失败？

MSDN对解释这些东西的实际工作原理几乎没有用处。

- Erix

---

当有许多待处理更改（1000多个）时，我发现SaveChanges()中花费大部分时间的是数据验证（DataAnnotations）。 - jrummell

你是使用一个 DbContext 还是为每一行创建一个新的 DbContext？ - Wim

@Wim 对于每一行都是一个新的，我们使用（var context = new DataEntities（））{进行编写...} - Erix

Answer 1

请阅读MSDN中的性能考虑，并查看Entity Framework中最快的插入方式。

- Wim

Answer 2

我不知道它的内部工作原理，但是在这种情况下，最好将数据插入队列中，并使用一个或多个（但有限的）线程来清空队列并写入数据库。您可以测试和调整线程数量，以便不会丢失数据。

- Amiram Korach