ITPub博客

首页 > Linux操作系统 > Linux操作系统 > oracle sql tuning 10 理解优化器访问路径

oracle sql tuning 10 理解优化器访问路径

原创 Linux操作系统 作者:oracle_db 时间:2010-04-07 16:08:50 0 删除 编辑

索引扫描可以有以下一些类型:

  • Assessing I/O for Blocks, not Rows

  • Index Unique Scans

  • Index Range Scans

  • Index Range Scans Descending

  • Index Skip Scans

  • Full Scans

  • Fast Full Index Scans

  • Index Joins

  • Bitmap Indexes

    Assessing I/O for Blocks, not Rows[通过块访问IO,而不是行]

      oracle通过块来操作IO,优化器决定是否使用全表扫描与访问的块的比例有关系,而不是与行有关系。这叫做:index clustering factor 。如果块中只有一行,那么访问块和访问行都是一个效果[我想是速度上没有差异]。尽管如此,表经常有多行,分布在不同的块中.因此,我们希望将数据集中在少数块中,要不然它们就要占用大量的块。the clustering factor 是索引的一个属性,通常反应出表中类似索引列值在数据块中的分布情况. clustering factor 的值如果小一般说明:个别的行是集中在少数块中,如果值比较大则说明行分布比较散乱,随机。这个 clustering factor 大了不是好事哦

    Index Unique Scans[索引唯一扫描]

    这种扫描方式就返回一个rowid.如果语句中有unique或者PRIMARY KEY 约束就可以确保唯一行被访问.当所有的唯一索引列,或者主键索引被指定为等值条件时,就会走索引唯一扫描

    Index Range Scans[索引范围扫描]

  • 数据被取回,按照索引列升序的方式取回。如果数据必须要排序那么使用order by 不要依赖索引,如果索引能够用来满足ORDER BY,或者说与ORDER BY有相同效果时,使用索引范围扫描的属性将起到避免排序的作用.

    何时使用index range scans呢?

    当优化器发现一列或者更多索引列被指定用到条件中,比如以下条件

    • col1 = :b1

    • col1 < :b1

    • col1 > :b1

    • AND combination of the preceding conditions for leading columns in the index

    • col1 like 'ASD%' wild-card searches should not be in a leading position otherwise the condition col1 like '%ASD' does not result in a range scan.

    范围扫描避免排序,当索引列被用在order by ,group by 中时

     

     

    来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/15720542/viewspace-631541/ ,如需转载,请注明出处,否则将追究法律责任。

    请登录后发表评论 登录
    全部评论

    注册时间:2008-11-13

    • 博文量
      158
    • 访问量
      354230