ORACLE数据库测试数据插入速度
转载:http://blog.csdn.net/waterxcfg304/article/details/24252627 一,没有优化的速度:Executed in 69.436 seconds drop table t purge; create or replace procedure proc1 下面查看下proc1插入100000记录的执行时间
/*我们可以通过下面的语句查看此存储过程执行的具体步骤*/ 为了方便查看我用PL/SQL DEVELOPER 执行的上面语句,如下图: 从上面可以看出,每个语句都只是解析了一次,执行了一次,一共解析了10万次,也许你会问你上面只有7136行记录啊,你怎么说是解析了10万次呢。我可以告诉你肯定是解析了10万次,因为我的共享池空间不大,容纳不小10万条信息,根据FIFO 的原理你可以看出,现在我查出来的都是从92000多开始的SQL STATEMENT记录。我们知道这些SQL语句都是相似的没有必要解析10万次,即每一条语句都解析一次。这个PROC1 没有用绑定变量,这就是我们可以优化的地方。我们用绑定变量来重新测试下,下面的PROC2就只用解析一次就可以了,当然速度肯定会提高不少。 二,使用绑定变量优化后的速度:Executed in 26.505 seconds SQL> set timing on; 从上面可以看出,时间基本上减少了一半。 从上面的执行情况可以知道,解析了一次,执行了10万次。完全符合我们的猜想,所以速度大大提升了。 execute immediate是一种动态SQL的写法,常用于表名字段名是变量,入参的情况,由于表名不知道,所以不能直接写SQL ,所以要靠动态SQL语句传人表名和字段名参数拼接成SQLSTATEMENT,有execute immediate调用执行。但是我的这个例子完全可以不需要动态的,可以用静态的写好。 三,用静态改写后的速度:Executed in 19.391 seconds create or replace procedure proc3 SQL> set timing on; 从上面可以看出,proc3也实现了绑定变量,而且动态的特点是执行过程中再解析,而静态的SQL的特点是编译的过程是解析好的,所以上面的PRARSE_CALLS是0。注意这个和上面一个图比较,上面的时PARSE_CALLS 是1,而这个是0,所以静态的少了一个执行的时候的解析过程。 我们可以看出上面的三个PROC都是一条语句就commit一次,我们完全没有必要这样做,我们可以一起提交。如下例: commit的时把log_buffer里的信息通过LGWR写到online redo log里,触发LGWR写10万次,而且我们知道LGWR写的太频繁了。 四,批量提交的速度:Executed in 11.42 seconds drop table t purge; SQL> set timing on; 可以看出我们用的时间更少了。 五,集合写法的速度:Executed in 0.452 seconds /*下面的语句是由上面的一条一条的插入改为一整批的写进data buffer区里,所以比上面的快,批处理肯定比一个一个的执行快*/ SQL> set timing on; 这个是上面的前四种都是一条一条的插入的,我这个集合写法是一整批地写进到DATA BUFFER里,所以比上面的四种情况要快的多。 六,用直接路径写法速度(100万条记录):Executed in 1.514 seconds 注意此时我插入的记录数十上面的10倍,我是插入100万条记录只用了1.514 seconds. 注意:直接路径的写法比集合写法快事因为,insert into select .... 的方式是将数据首先写到data buffer里,然后再刷到磁盘里。而create as t 的方式跳过了数据缓冲区(data buffer), 直接写进磁盘中,这种方式称之为直接路径读写方式。本来是先到内存,在到磁盘,更改为直接到磁盘,少了一个步骤,所以速度快了。 七,并行写法的速度(100万条记录):Executed in 0.733 seconds /*并行加直接路径,而且是不写日志的,所以速度比上面的更快*/ SQL> set timing on; 我上面只用了parallel 4,如果更多的话,还会更快!!! (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |