早上挤公交时拜读了公司牛人的文章
http://mp.weixin.qq.com/s?_biz=MjM5MzExMTU2OQ==&mid=402651167&idx=1&sn=471fada84cb244779edca222dd2923f7&scene=4#wechat_redirect
介绍了一条简单sql不简单的优化,看完想起曾经遇到一些sql全表扫描比较慢,明明有索引就是不走,强制走索引反而更慢,生涯一大困扰得以破解。
然而以往的经验提醒我:oracle里能起到优化改善的措施必然伴随一定的风险!那么优化聚簇因子的好事会伴随什么风险呢?于是想到聚簇因子会不会不降反升、其他索引会怎么想、表能否容忍DBA动它的聚簇因子?
做了个实验,把表TASK的数据按索引1和2的引导列ID排序创建了表TASK2
整容前的表
整容后的表
整容前的索引
整容后的索引
可见索引1和2的聚簇因子明显降低,可改善相关的业务性能;但索引3和主键索引的聚簇因子却大大增加,肯定会影响相关业务。
所以优化索引的聚簇因子一定要考虑相同表上其他索引的业务情况,不能拆东墙补西墙;降低聚簇因子的操作也会影响表的在线情况,维护需要成本,能不能动也要看表给不给约(此处想到在线重定义应该可以很好地完成数据按需排序重建);至于过一段时间后聚簇因子会不会升高,我这没实验,但我想如果数据有变动,原有的排序必然受影响,聚簇因子也会升高。
http://mp.weixin.qq.com/s?_biz=MjM5MzExMTU2OQ==&mid=402651167&idx=1&sn=471fada84cb244779edca222dd2923f7&scene=4#wechat_redirect
介绍了一条简单sql不简单的优化,看完想起曾经遇到一些sql全表扫描比较慢,明明有索引就是不走,强制走索引反而更慢,生涯一大困扰得以破解。
然而以往的经验提醒我:oracle里能起到优化改善的措施必然伴随一定的风险!那么优化聚簇因子的好事会伴随什么风险呢?于是想到聚簇因子会不会不降反升、其他索引会怎么想、表能否容忍DBA动它的聚簇因子?
做了个实验,把表TASK的数据按索引1和2的引导列ID排序创建了表TASK2
整容前的表
TABLE_NAME | NUM_ROWS | BLOCKS |
TASK | 15396350 | 236044 |
TABLE_NAME | NUM_ROWS | BLOCKS |
TASK2 | 15396350 | 236044 |
INDEX_NAME | CLUSTERING_FACTOR |
TASK_INDEX1 | 14900640 |
TASK_INDEX2 | 14719830 |
TASK_INDEX3 | 362400 |
PK_TASK | 592060 |
INDEX_NAME | CLUSTERING_FACTOR |
TASK2_INDEX1 | 1890090 |
TASK2_INDEX2 | 709040 |
TASK2_INDEX3 | 13609440 |
PK_TASK2 | 14465190 |
所以优化索引的聚簇因子一定要考虑相同表上其他索引的业务情况,不能拆东墙补西墙;降低聚簇因子的操作也会影响表的在线情况,维护需要成本,能不能动也要看表给不给约(此处想到在线重定义应该可以很好地完成数据按需排序重建);至于过一段时间后聚簇因子会不会升高,我这没实验,但我想如果数据有变动,原有的排序必然受影响,聚簇因子也会升高。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/26614613/viewspace-2061227/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/26614613/viewspace-2061227/