本来不想测试DBMS_OBFUSCATION_TOOLKIT.md5的效率的,可是事先没有想到dbms_crypto.hash与dbms_utility.get_hash_value的效率会差距这么大,所以看来还是有必要测试下DBMS_OBFUSCATION_TOOLKIT.md5的效率。
[@more@]
还是那用个很大表的SUNWG来测试吧。
SQL> select count(*) from sunwg;
COUNT(*)
----------
5000000
SQL> create table sunwg_md5 as select md5(id) id from sunwg;
Table created
Executed in 148.062 seconds
SQL> create table sunwg_get_hash as select dbms_utility.get_hash_value(utl_raw.cast_to_raw(id),1,10000000) id from sunwg;
Table created
Executed in 136.266 seconds
可以看的出来其实DBMS_OBFUSCATION_TOOLKIT.md5和dbms_utility.get_hash_value的效率差得就不是太多了。但是dbms_utility.get_hash_value使用起来会更加的方便一些,所以下面就对dbms_utility.get_hash_value进行一些详细的测试。
上一篇文章通过测试发现,参数HASH_SIZE对dbms_utility.get_hash_value并没有什么影响。那到底什么会对dbms_utility.get_hash_value的效率有影响呢。大概猜一下应该两个方面,一个是执行dbms_utility.get_hash_value操作的记录的条数,再一个就是记录中字符的总的长度。下面就分别进行一下测试吧。为了篇幅我就仅仅贴出执行的结果。
ROW NUMBER | TIMING |
1 | 0.00s |
100 | 0.078s |
1000 | 0.125s |
10000 | 0.313s |
100000 | 2.484s |
1000000 | 29.375s |
2000000 | 61.109s |
3000000 | 87.797s |
4000000 | 116.062s |
5000000 | 136.266s |
从上面的结果可以看出来,随着记录数的增加,时间成线性增长。
LENGTH(ID) | TIMING |
1 | 98.234s |
10 | 102.687s |
30 | 106.531s |
50 | 112.641 |
70 | 118.812 |
100 | 127.313 |
200 | 148.484s |
400 | 195.188 |
从上面的结果可以看出来,随着记录长度的增加,时间增长的速度并不快。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/8394333/viewspace-996358/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/8394333/viewspace-996358/