事务提交的频率

看看在看文档的时候突然想起了一个问题。

曾经面试过的一个公司，提问我这么一个问题：你要执行insert into或者update数据量在1W(以上)的大量记录的语句，如何处置commit？当时的我刚刚参加工作，刚刚接触到oracle一段时间，也刚刚阅读了"大量"的oracle基础知识、。。。。。。，然后我答到：最后是立即提交。汗，多么幼稚的答案，如果是1w条的insert语句，在每个语句之后插入commit，手估计都要抽筋了吧，虽然有编辑器的宏等等高级功能。总之，这个答案是失败的答案。

那么，比较正确和合理的答案是什么呢？比较正确和合理的答案就是最简单的做法，在事务结束之后执行提交，不要在事务之间提交，不要使用过程性循环处理语句。

举个例子，就很好说明了：你要执行1张表中的1w条记录，如果你在每100条之后执行一个commit，在执行第101条的update时候，事务失败了。

这个时候第100条之前的记录已经被update并且被commit了，这个事务是失败的，但是又有你不知道的100条记录被update且commit了，这个时候应该是很郁闷了吧，不知道如何重新启动这个事务了。你知道你失败了，但是不知道从哪里爬起来。！

其次，分开提交，比单个sql语句更慢。

第3，已经被commit的undo会有被覆盖的风险，而根据事务一致性和多版本能控制的特性，update是一边查询一边修改的执行，如果构造此次事务的undo空间被覆盖，你将收到经典的ORA-01555:snapshot too old的错误。

第4。。。我也不知道。

以上3点足够我们放弃这个误导性的观点：过程性循环性处理大更新的提交工作。

-The End-