一个诡异的存储过程

全表扫描与索引扫描对比，并不是索引扫描一定快，大师有句名言：“避免不必要的全表扫描”，因为全表扫描时多块读，大部分索引扫描是单块读，不同场景运用不同的方式。不知道这里的Oracle版本是多少？从10g以后只有CBO这种优化器，它会根据统计信息自动计算一条SQL的不同执行路径，然后选择一条成本最低的作为他的执行计划，因此一条SQL的执行计划可能是全表扫描，也可能是索引扫描，例如一张表只有100条数据，全表扫描肯定比索引扫描要快，这要具体问题具体分析，如果想知道为什么上述不同的现象，请用10053做这两条SQL的trace，可以看下Oracle选择的成本值。

解决方案 »

  1.   

    最好贴出你的执行计划，10053的trace日志，这样可以更详细地看下为什么效果不同。
      

  2.   

    刚到6L，结贴有点浪费，\(^o^)/~
    又原因分享Oracle知识的，请贴出来，结贴都给分。
      

  3.   

    看样子，是你执行 test 时，并没有真正的去执行这两个 sql，只是确定了执行计划，你点击 cursor 输出时，才真正去跑这些语句。
      

  4.   

    如果没猜错，sj.i_zhangwuny 这个字段是 varchar2 类型，
    你试试把 201311 改成 '201311' 再执行sql二。如果速度也很快，基本就可以解释了。
    plsql在test时候，输入的应该是按照字符串传了。
      

  5.   

    i_zhangwuny是int类型
    varchar类型的字段，我们命名是以S_开头的
    呵呵
      

  6.   

    那就把你的执行计划贴出来。i_zhangwuny是int类型
    varchar类型的字段，我们命名是以S_开头的
    呵呵
      

  7.   

    i_zhangwuny是int类型
    varchar类型的字段，我们命名是以S_开头的
    呵呵很久之前的事情了，后来通过其他方式把这个存储过程执行效率的问题处理了。现在让我拿执行计划出来，拿不出来的了
      

  8.   

    我擦，才看见13年的帖子。
    一般情况你这种情况基本是因为隐士类型转换到值的索引失效。
    既然时间已经久远就不提他了。i_zhangwuny是int类型
    varchar类型的字段，我们命名是以S_开头的
    呵呵很久之前的事情了，后来通过其他方式把这个存储过程执行效率的问题处理了。现在让我拿执行计划出来，拿不出来的了
      

  9.   

    i_zhangwuny是int类型
    varchar类型的字段，我们命名是以S_开头的
    呵呵很久之前的事情了，后来通过其他方式把这个存储过程执行效率的问题处理了。现在让我拿执行计划出来，拿不出来的了恩，不再提它了。
    可以在此帖分享Oracle知识，分享给分，当然了帖子分数不高:-)