事务中的换行插入对Sql Server的性能有多大帮助？

假设我有100行要插入，每行大约有150列（我知道这听起来像是很多列，但我需要将这些数据存储在一个表中）。插入将随机发生（即当一组用户决定上载包含数据的文件时），大约每月20次。但是，数据库将在大型企业应用程序的其他功能的连续加载下处理。列包括varchars、int以及各种其他类型

在事务中包装这些插入（而不是一次运行一个插入）的性能增益是巨大的、最小的还是介于两者之间的

为什么?

编辑：

---

这是针对SQLServer2005的，但如果有什么不同的说法，我会对2000/2008感兴趣。我还应该提到，我理解事务主要用于数据一致性的观点，但我想重点关注性能影响。

这取决于您所说的巨大，但它会有所帮助（这实际上取决于您所做的插入的总数）。它将强制SQL Server在每次插入后都不执行提交操作，这在时间上是累积的。对于100个插入，您可能不会注意到太多的增加，这取决于数据库的频率和其他情况。

实际上可能会产生影响。事务的重点不在于你做了多少，而在于保持数据更新的一致性。如果您有需要插入在一起且相互依赖的行，则这些是您在事务中包装的记录

事务是关于保持数据一致性的。这应该是您在使用事务时首先考虑的事情。例如，如果您的支票账户有借方（取款），您需要确保贷方（存款）也已完成。如果其中任何一个都没有成功，整个“事务”应该回滚。因此，这两个操作必须包装在一个事务中

在执行批插入时，将它们拆分为3000或5000条记录，并在集合中循环。3000-5000对于我来说是一个甜蜜的数字范围；除非您已经测试了服务器是否可以处理它，否则不要超过这一点。另外，我将把GOs放入批中，大约每3000或5000条记录插入一次。更新和删除我将设置为大约1000，因为它们需要更多的资源来提交

---

如果您是从C代码执行此操作，那么在我看来，您应该构建一个批导入例程，而不是通过编码一次执行数百万次插入。

事务不是为了性能，而是为了数据完整性。根据实现的不同，只有100行真正没有性能增益/损失（它们只是被额外记录，所以它们都可以回滚）

<> P>关于性能问题的考虑：

• 助教将与其他查询交互 写入TA将锁定元组/页面/文件
• 提交可能只是（取决于锁协议）时间戳的更新
• 可能会为TA编写更多日志（应该能够回滚TA，但是DB可能已经大量记录了，顺序记录很便宜）
• 隔离度（我知道在某些DBs中可以切换此级别，而且几乎没有人使用级别3）

---

总而言之：使用TA来确保完整性。

正如其他人所说，事务与性能无关，而是与数据的完整性有关

---

话虽如此，当您只想每月插入大约20次100行数据（意味着每月插入2000条记录）时，担心性能是愚蠢的。过早优化是浪费时间；除非您反复测试了这些插入对性能的影响（尽管它们很小，而且很少），并发现它们是一个主要问题，否则不要担心性能。与您提到的服务器负载相比，这是微不足道的。

虽然事务是保持数据一致性的一种机制，但如果使用不当或过度使用，它们实际上会对性能产生巨大影响。我刚刚完成了一篇关于显式指定事务而不是让事务自然发生对性能的影响的文章

如果要插入多行，并且每次插入都发生在自己的事务中，那么锁定和解锁数据会有很大的开销。通过将所有插入封装在单个事务中，可以显著提高性能

相反，如果有许多查询在数据库上运行，并且也发生了大型事务，则它们可能会相互阻塞，并导致性能问题

---

事务与性能有着明确的联系，而不管其潜在意图是什么。

实际上是非常重要的。对于大型插入，100++（假设您将mysql配置为增加查询大小和事务大小以支持庞大的查询/事务，很抱歉，不记得确切的变量名）-插入时间通常可以是10倍快，甚至更高

是的，这是我的想法，但我被告知不是这样，这也是我问这个问题的部分原因。不，除了维护数据完整性之外，如果将大量行插入到一起，事务确实会对性能产生影响。在一个事务中执行这些操作可以降低所需的总IOPS。@PratikSinghal：在本海报的问题中不是这样。插入的行数可以忽略不计。在2000/2008之间，没有什么值得注意的差异。性能提升和事务一致性几乎总是相互矛盾的。模式设计、索引体系结构和存储方法/最佳做法将决定您的性能提升。处理数据时的第一条经验法则是，使数据请求和操作尽可能小