我目前处于一种情况,我正在构建一个我知道需要插入多行的脚本。我在Perl中这样做,所以在参数化方面,单独插入每一行要容易得多。在速度方面,我猜测只运行一个插入语句会更快(虽然延迟会相对较低,因为我非常接近数据库本身)。我认为每次运行脚本的行数平均约为20-40。也就是说,运行1 INSERT INTO语句vs.s之间的大致性能差异是什么?为每一行运行一个?注意:服务器正在运行SQL 2008。
[编辑]由于似乎存在很多混淆,我想澄清一下,我真正要求的是SQL Server 2008如何处理多行插入的理论。它本质上是只是将其内部转换为一堆单独的插入语句并通过一个连接运行它们,还是做一些更聪明的事情?
是的,我知道我可以运行定时循环。不,那不是我要求的。 [/编辑]
答案 0 :(得分:5)
将多个插入组合到一个命令中总是比执行单独的插入更快地执行多。原因是:
答案 1 :(得分:3)
一般的想法是让SQL数据库做它的事情,而不是试图将数据库视为某种磁盘读取。我已经多次看到开发人员会从一个表中读取,然后是另一个表,或者执行一般查询,然后遍历每一行以查看它是否是他们想要的那个。通常,让SQL数据库做它的事情会更好。
在这种情况下,我无法真正看到执行单行与多行插入的优势。我想可能有一些因为你不需要做多次准备和提交。
实际创建临时数据库并尝试这一点应该不会太困难。创建一个包含两列的数据库,让程序生成数据以折叠到表中。给自己一个不错的数量。例如,此表有多少项?而且,您认为您将立即插入多少个?假设创建一个包含1,000,000个项目的表格,并一次插入1000个项目,一次插入100个项目,一次插入一个项目。只需使用increment运算符生成数据。您可以一次插入多少项目的“甜点”。
在我的公正和始终正确的意见中,你可能会发现差异不值得烦恼,你应该采用使你的代码最容易维护的方法。
我有一个编程格言:您想要优化代码的地方可能是错误的地方。我们喜欢效率,但我们通常会攻击错误的项目。而且,无论我们在效率方面如何挤压,我们最终都会浪费在维护上。
因此,只需编制最容易理解的内容,并且不要担心过度有效。
答案 2 :(得分:1)
添加一些其他性能差异因素来考虑插入:
外键 - 如果要插入的表具有外键,则SQL Server实际上需要连接到插入时的外键表。在一个查询中执行插入操作时,SQL Server可以更有效地执行这些连接。
交易 - 由于您没有提及交易,我假设您必须使用SQL Server自动提交模式。如此少量的行,创建40个事务与1个事务的开销可能高于维护日志以允许回滚。但是,如果要插入400000行,插入一个语句/事务可能比插入400000个单独行更昂贵,因为要准备回滚到400000行的成本非常高(如果要插入400000)行,通常最好分批插入 - >最佳批量大小可以通过测试确定)。此外,在某个行数以上,禁用外键,插入行,然后重新启用它们可能会更有效。