SQL不走索引探究

        应用反映平时运行得正常的SQL最近变慢了，发现某些SQL执行计划改变了，未利用上索引，通过10053事件进行跟踪，终于发现其中端倪。

SQL:  select userid,readflag from inbox a
   where emailid like '0201101130958%'; 

Plan
SELECT STATEMENT HINT: ALL_ROWS Cost: 85,244 Bytes: 11,858,280 Cardinality: 169,404
	2 PARTITION RANGE ALL Cost: 85,244 Bytes: 11,858,280 Cardinality: 169,404 Partition #: 1 Partitions accessed #1 - #54
		1 TABLE ACCESS FULL TABLE BBGOA.INBOX Cost: 85,244 Bytes: 11,858,280 Cardinality: 169,404 Partition #: 1 Partitions accessed #1 - #54

   

   

    数据库环境为ORACLE 10.2.0.4,优化器模式参数为默认的ALL_ROWS,在该表上emailid 创建有普通索引，且都对表和索引进行过统计，通过INDEX RANGE SCAN 效率要比FTS全表扫描要快得多，为何执行计划不走索引而要选择执行时间更久的FTS，下面我通过10053进行跟踪来看看实际的执行计划。如何跟踪请查阅我的另一篇日志: http://space.itpub.net/611609/viewspace-683744。

 

 

***************************************

BASE STATISTICAL INFORMATION

***********************

Table Stats::

  Table: INBOX  Alias:  A  (Using composite stats)

    #Rows: 1270529  #Blks:  388549  AvgRowLen:  1760.00

Index Stats::

  Index: IDX_INBOX_EMAILID  Col#: 2

    LVLS: 2  #LB: 12084  #DK: 458007  LB/K: 1.00  DB/K: 2.00  CLUF: 1021384.00

  Index: IDX_INBOX_USERID_EMAILID  Col#: 1 2

    LVLS: 3  #LB: 14713  #DK: 1270517  LB/K: 1.00  DB/K: 1.00  CLUF: 1269392.00

  Index: SYS_IL0000013587C00006$$  Col#:

    USING COMPOSITE STATS    (NOT ANALYZED)

    LVLS: 1  #LB: 25  #DK: 100  LB/K: 1.00  DB/K: 1.00  CLUF: 800.00

***************************************

SINGLE TABLE ACCESS PATH

  -----------------------------------------

  BEGIN Single Table Cardinality Estimation

  -----------------------------------------

  Column (#2): EMAILID(VARCHAR2)

    AvgLen: 54.00 NDV: 17966 Nulls: 0 Density: 4.2314e-05

    Histogram: HtBal  #Bkts: 75  UncompBkts: 75  EndPtVals: 62

  Table: INBOX  Alias: A

    Card: Original: 1270529  Rounded: 169404  Computed: 169403.87  Non Adjusted: 169403.87

  -----------------------------------------

  END   Single Table Cardinality Estimation

  -----------------------------------------

  Access Path: TableScan

    Cost:  85243.65  Resp: 85243.65  Degree: 0

      Cost_io: 84997.00  Cost_cpu: 3130399701

      Resp_io: 84997.00  Resp_cpu: 3130399701

kkofmx: index filter:"A"."EMAILID" LIKE '0000000000000000000000000000000000麓梅忙锚戮虏201101130958%'

kkofmx: index filter:"A"."EMAILID" LIKE '0000000000000000000000000000000000麓梅忙锚戮虏201101130958%'

  Access Path: index (RangeScan)

    Index: IDX_INBOX_EMAILID

    resc_io: 137799.00  resc_cpu: 1064338211

    ix_sel: 0.13333  ix_sel_with_filters: 0.13333

    Cost: 137882.86  Resp: 137882.86  Degree: 1

  Access Path: index (skip-scan)

    SS sel: 0.13333  ANDV (#skips): 169402

    SS io: 169402.27 vs. table scan io: 84997.00

Skip Scan rejected

 

单表Index CBO 的计算方法： LVL + (Sel * LB)        + (Sel * CLUF)=2+（0.13333*12084）+（0.1333*1021384）=137794.3

 

CLUSTERING_FACTOR列的值用以表示索引的数据和相应表的数据是否有很好的对应关系。如果该值接近于表的块数，那么说明表中的数据分布是均匀有规则的，这种情况下索引叶块的索引条目通常指向表中同一个数据块的行数据；如果接近于表的行数的话，那么说明表中的数据分布是很凌乱的，同一叶块的索引条目指向的行数据可能分散在表中不同的数据块上，通过索引访问大范围数据的话需要重复读取相同数据块，导致索引效率不高。关于CLUSTERING_FACTOR解释祥见metalink docid:39836.1。

 

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

转载于:http://blog.itpub.net/611609/viewspace-683828/