频繁保存数百万个条目的数据库效率？ [复制]答案

【问题标题】：Frequent saving database efficient with millions of entries? [duplicate]频繁保存数百万个条目的数据库效率？ [复制]
【发布时间】：2019-01-18 01:45:05
【问题描述】：

我正在尝试将大量数据插入 SQL Server 数据库，我的问题是，当数百万个条目将被插入到那里时，我应该多久保存一次。在例如之后保存它是否有效？ 10.000 次插入还是 1.000.000 次插入之后？有什么值得参考的价值观吗？我使用C# Entity Framework 用数据填充服务器，所以我使用DBContext 类来处理CRUD 和保存。

【问题讨论】：

“保存”到底是什么意思？运行 INSERT 命令后，该行（或多行）的数据就在数据库中，除非您正在使用事务，在这种情况下，它会一直等到您提交事务。你到底是如何插入数据的？或者您是在谈论进行备份，也许？另外，为什么您认为更改此“保存”点可能会影响效率？以什么方式？你期望获得什么？恐怕根本不清楚你在问什么。
这是一个非常广泛的问题。根据您的问题，听起来 SQL Server 并不是处理链中的唯一部分。 SQL Server 被设计为高效，但它也必须知道您希望它高效地做什么，因此数据库设计是一个主要因素（表结构、索引等）。如果不知道您的应用程序的架构，我们真的无法为您回答这个问题。
啊，所以您可能是在谈论在实体框架中使用 SaveChanges() ？这有效地在后台提交了事务。我认为它不会对“效率”产生太大影响，尽管这本身就是一个非常广泛的术语。如果您正在执行如此大量的负载，我假设您此时并不担心并发访问，或者是吗？如果你想让你的加载过程更快，根本不要使用实体框架，使用合适的批量加载工具
ericlippert.com/2012/12/17/performance-rant
别忘了设置 AutoDetectChangesEnabled = false;在 DbContext 上。见这里stackoverflow.com/questions/5943394/…

标签： c# sql-server database entity-framework sql-scripts

【解决方案1】：

我正在使用 C# Entity Framework 向服务器填充数据

您的问题从这里开始。它不适合这个。错误的工具。我喜欢Entity Frameowrk，但它是一个ORM，而不是批量加载工具。

我通常使用 SqlBulkLoader 类将多达 65k 条记录加载到一个临时表中（在几秒钟内，但要注意，您几乎必须使用一个临时表），我在一个命令/事务中将其 ncopy 到最终表。

以全速并行处理 4-5 个线程。

实体框架将花费数小时处理一百万行，无论您如何打开它。只是错误的工具。

【讨论】：

另请查看SSIS 和Bulk Copy