在事务中包装插入对 Sql Server 的性能有多大帮助？

Question

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

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

为什么？

编辑：这是针对 Sql Server 2005，但如果有不同的说法，我会对 2000/2008 感兴趣。 另外我应该提到我理解事务主要是为了数据一致性的观点，但我想专注于性能影响。

Answer 1

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

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

进行批量插入时，将它们分成 3000 或 5000 条记录，然后在整个集合中循环。 3000-5000 对我来说是一个很好的插入数字范围； 除非您已经测试过服务器可以处理它，否则不要超过它。 此外，我将大约每 3000 或 5000 条记录将 GO 放入批处理中以进行插入。 更新和删除 我将 GO 设置为大约 1000，因为它们需要更多资源来提交。

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

Answer 2

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

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

相反，如果您有许多针对您的数据库运行的查询并且同时发生大型事务，它们可能会相互阻塞并导致性能问题。

交易与绩效有着明确的联系，无论其潜在意图如何。

Answer 3

这取决于你所说的巨大，但它会有所帮助（这实际上取决于你正在做的插入的总数）。 它将强制 SQL Server 在每次插入后不进行提交，这会及时累加。 对于 100 次插入，您可能不会注意到增加太多，具体取决于数据库发生的频率和其他情况。

Answer 4

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

话虽如此，当您只谈论每月插入 100 行数据大约 20 次（意味着每月 2000 条记录）时，以一种或另一种方式担心性能是愚蠢的。 过早的优化是浪费时间； 除非您反复测试了这些插入的性能影响（尽管它们很小，但很少出现）并发现它们是一个主要问题，否则不要担心性能。 与您提到的其他服务器负载相比，它可以忽略不计。

Answer 5

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

关于性能问题需要考虑的事项：

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

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

Answer 6

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