大佬教程收集整理的这篇文章主要介绍了Oracle构造序列的方法分析对比，大佬教程大佬觉得挺不错的，现在分享给大家，也给大家做个参考。
《Oracle构造序列的方法分析对比》要点：
本文介绍了Oracle构造序列的方法分析对比，希望对您有用。如果有疑问，可以联系我们。
编辑手记：关于Oracle的序列,相信大家并不陌生,但很多人平时只用到connect by 的方式来构造序列,今天一起来学习更多的构造序列的方法及每个方法的优缺点.
作者介绍
正文
Oracle构造序列的方法随着版本一直在变化.在9i之前的版本,常用的方法是：
从all_objects等系统视图中去获取序列的方式,虽然简单,但有一个致命的弱点是该视图的sql非常复杂,嵌套层数很多,一旦应用到真实案例中,极有可能碰到Oracle自身的bug,所以这种方式不考虑,直接pass掉.
2、9i之后,我们用connect by
3、自从10g开始支持XML后,还可以使用以下方式：
接下来我们从序列大小,构造时间等方面对比分析这两种方式.
可见直接用connect by去构造较大的序列时,消耗的资源很多,速度也快不到哪儿去.实际上2^20并不是一个很大的数字,就是1M而已.
但xmltable方式就不会耗这么多资源
其实除了上述三种办法,我们还可以使用笛卡尔积来构造序列.如果换成笛卡尔连接的方式,那么构造2^20时,connect by也ok
我们试着将1M加大到1G,在connect by方式下
耗时高达1分钟还多,再看看xmltable方式,考虑到1M的时候耗时就达到0.95秒,因此这里只测试1/16*1G,即64M的情况
如果直接构造到1G,那么时间差不多是16*37s这个级别.
但如果通过笛卡尔积＋xmltable的方式来构造.
这时间和connect by的差不多.以上测试,总的可见,在构造较大序列时,笛卡尔积的方式是最佳的,单纯使用COnnect by会遭遇内存不足,而单独使用Xmltable则会耗费较多的时间.
现在再看看基本用纯表连接的方式来构造同样大小的序列,先来1M的
再来64M的
这个速度并不快,但已经比直接xmltable快了.
其实64M,即64*2^20可以表示为(2^5)^5*2,那我们来改写一下64M的sql
可以看到,从16s到4s,已经快了很多.这个示例告诉我们,中间表c 在提高速度方面起到了很好的作用.
但在构造到1G时,还是要慢一些
尝试相对较快的写法,多一层中间表
更快一点(思路,32^2=1024,1G=2^30=(2^5)^6=((2^5)^2)^3 .)
这时候我们将2^5＝32换成直接构造出来的方式
可见所耗费的时间差不多.
由此我们还可以得出,表连接的代价其实也是昂贵的,适当的减少表连接的次数,适当的使用with里的中间表,能有效提高系统性能.
再重复一下刚才构造64M(2^26)的场景
总共25次的表连接,1层嵌套,让速度非常慢.提高一下(26=4*3*2+2*2),总共8次表连接,3层嵌套.
效率提升4倍.要注意在这个案例中并非表连接越少越好,嵌套层数也是需要关注的指标.执行计划有兴趣的同学自己去看吧,我就不列了,上例中,系统生成的中间表有3个.
最终结论,构造较大序列时,例如同样是构造出64M的序列,Oracle在处理时,用表连接的方式明显占优.但考虑到书写的便利性,因此在构造较小序列的时候,比如不超过1K的序列,那么直接用connect by或xmltable的方式就好了.
附：newkid 回复方法,表示更灵活,有兴趣的同学可以尝试：
文章来自微信公众号：数据和云
以上是大佬教程为你收集整理的Oracle构造序列的方法分析对比全部内容，希望文章能够帮你解决Oracle构造序列的方法分析对比所遇到的程序开发问题。
如果觉得大佬教程网站内容还不错，欢迎将大佬教程推荐给程序员好友。
本图文内容来源于网友网络收集整理提供，作为学习参考使用，版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ：384754419，请注明来意。