在事务中包装插入有多少可以帮助在Sql Server上实现性能？

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

将这些插入包装在一个事务中(而不是一次运行一个)的性能提升是巨大的,最小的,还是介于两者之间？

为什么？

编辑:这是为Sql Server 2005,但如果有不同的话,我会对2000/2008感兴趣.另外我应该提一下,我理解交易主要是为了数据一致性,但我想关注性能影响.

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

交易是关于保持数据的一致性.这应该是您在使用交易时首先考虑的事情.例如,如果您从支票帐户中扣款(取款),则需要确保信用(存款)也已完成.如果其中任何一个不成功,则应回滚整个"事务".因此,两个动作必须包含在事务中.

进行批量插入时,将它们分解为3000或5000条记录并循环显示.3000-5000对我来说是一个甜蜜的编号范围; 除非你已经测试过服务器可以处理它,否则不要超过它.此外,我将把批次中的GO放在大约每3000或5000个记录中用于插入.更新和删除我将GO放在大约1000,因为它们需要更多的资源来提交.

如果你是用C#代码做的,那么在我看来,你应该建立一个批量导入例程,而不是通过编码一次做一百万个插入.

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

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

相反,如果您针对数据库运行了许多查询并且还发生了大量事务,则它们可能会相互阻塞并导致性能问题.

无论其潜在意图如何,交易都与绩效明确相关.