oracle中列值的集簇因子研究

《oracle中列值的集簇因子研究》由会员上传分享，免费在线阅读，更多相关内容在教育资源-天天文库。

1、列值的选择性、集簇和柱状图切记，优化器了解表中列数据的许多重要特征，最显著的是列值的选择性和列的集簇因子。例如，以下我们看到一个使用列值来形成结果集的查询：selectcustomer_namefromcustomerwherecustomer_state='RhodeIsland';在此示例中，选择使用索引还是全表扫描受到罗得岛客户比例的影响。如果罗得岛客户的比例非常小，并且数值集簇在数据块中，则对于此查询而言索引扫描可能是最快的执行计划。许多Oracle开发人员对于当他们只检索很少量的行时优化器选择全表扫描而感到困惑，而没有意识到优化器考虑了表中列值的集簇。Oracle在dba

2、_indexes视图中提供一个名为clustering_factor的列，通知优化器关于表的行与索引的同步情况。当集簇因子接近数据块的数量时，表的行与索引同步。列值的选择性、db_block_size、avg_row_len以及集合基数全都协同工作，帮助优化器决定是使用索引还是使用全表扫描。如果数据列具有高度的选择性和低的clustering_factor，则索引扫描通常是最快的执行方法（参见图2）。如果多数SQL引用了具有高clustering_factor、大db_block_size和小avg_row_len的列，则DBA有时会周期性地对表的行进行重排序或使用单表集簇来维持行

3、的顺序。这种方法将所有相邻的行放置在同一数据块中，消除了全表扫描，使查询速度的增加高达30倍。相反，高clustering_factor的数值达到表中的行数(num_rows)，表明这些行的顺序与索引中的顺序不同，索引范围扫描将会需要额外的I/O。由于clustering_factor达到表中的行数，这些行与索引不同步。但是，即使列具有高度的选择性，高clustering_factor和小avg_row_len也会表示列值在表中随机分布，而获取这些行需要额外的I/O。在此情况下，索引范围扫描会导致大量不必要的I/O（参见图3）；全表扫描则会高效得多。总而言之，clustering_

4、factor、db_block_size和avg_row_len全都影响优化器有关执行全表扫描或是索引范围扫描的决策，理解优化器如何使用这些统计信息非常重要。我们已经注意到，每个新版本的优化器都有改进，并且OracleDatabase10g提供的最新增强特性在确定执行计划时会考虑外部的影响。Oracle称此特性为外部成本核算，并包括对CPU和I/O成本的评估。Ora10g需要插入比较多的行才能够有变化。以下例子来说明列值的集簇因子对执行计划产生的影响：1、搭建环境SQL>insertintotestselect*fromemp;14rowscreated.Commitcomplet

5、e.2、分析表SQL>analyzetabletestcomputestatistics;Tableanalyzed.3、查看列值的集簇因子：selectt.table_name,t.NUM_ROWS,t.BLOCKS,t.AVG_ROW_LEN,i.index_name,i.CLUSTERING_FACTORfromdba_tablest,dba_indexesiwheret.table_name=i.table_nameandt.owner='SCOTT'andt.table_name='TEST';TABLE_NAMENUM_ROWSBLOCKSAVG_ROW_LENINDE

6、X_NAMECLUSTERING_FACTOR--------------------------------------------------------------------TEST14132TEST_ENAME14、使用索引列进行查询：SQL>select*fromtestwhereename='CUUG1';norowsselectedExecutionPlan----------------------------------------------------------0SELECTSTATEMENTOptimizer=CHOOSE(Cost=2Card=1Byt

7、es=32)10TABLEACCESS(FULL)OF'TEST'(TABLE)(Cost=2Card=1Bytes=32)Statistics----------------------------------------------------------1recursivecalls0dbblockgets3consistentgets0physicalreads0redosize615bytessentviaSQL*Nettoclient376bytesrec