Mar*_*ers 9 sql database sql-server performance transactions
好的说我要插入100行,每行有大约150列(我知道这听起来像很多列,但我需要将这些数据存储在一个表中).插入将随机发生(即,每当一组用户决定上传包含数据的文件时),大约每月20次.但是,数据库将在连续加载处理大型企业应用程序的其他功能.列是varchars,int,以及各种其他类型.
将这些插入包装在一个事务中(而不是一次运行一个)的性能提升是巨大的,最小的,还是介于两者之间？
为什么？
编辑:这是为Sql Server 2005,但如果有不同的话,我会对2000/2008感兴趣.另外我应该提一下,我理解交易主要是为了数据一致性,但我想关注性能影响.
Sna*_*Jag 17
它实际上可能是一种影响.交易点不是关于你做了多少,而是关于保持数据更新的一致性.如果您有需要一起插入并且相互依赖的行,那么这些是您在事务中包装的记录.
交易是关于保持数据的一致性.这应该是您在使用交易时首先考虑的事情.例如,如果您从支票帐户中扣款(取款),则需要确保信用(存款)也已完成.如果其中任何一个不成功,则应回滚整个"事务".因此,两个动作必须包含在事务中.
进行批量插入时,将它们分解为3000或5000条记录并循环显示.3000-5000对我来说是一个甜蜜的编号范围; 除非你已经测试过服务器可以处理它,否则不要超过它.此外,我将把批次中的GO放在大约每3000或5000个记录中用于插入.更新和删除我将GO放在大约1000,因为它们需要更多的资源来提交.
如果你是用C#代码做的,那么在我看来,你应该建立一个批量导入例程,而不是通过编码一次做一百万个插入.
虽然事务是一种保持数据一致的机制,但如果它们被错误地使用或过度使用,它们实际上会对性能产生巨大影响.我刚刚完成了一篇关于明确指定事务的性能影响的博客文章,而不是让它们自然发生.
如果要插入多行,并且每个插入都发生在自己的事务中,则锁定和解锁数据会产生大量开销.通过在单个事务中封装所有插入,您可以显着提高性能.
相反,如果您针对数据库运行了许多查询并且还发生了大量事务,则它们可能会相互阻塞并导致性能问题.
无论其潜在意图如何,交易都与绩效明确相关.
正如其他人所说，事务与性能无关，而是与数据的完整性有关。
话虽这么说，当您只谈论每月大约 20 次插入 100 行数据（意味着每月 2000 条记录）时，以某种方式担心性能是愚蠢的。过早的优化是浪费时间；除非您反复测试了这些插入对性能的影响（尽管它们很小且不频繁）并发现它们是一个主要问题，否则不要担心性能。与您提到的服务器负载的其他因素相比，它可以忽略不计。