ORACLE中大数据量下索引效率的测试与分析.docVIP

ORACLE中大数据量下索引效率的测试与分析 删除Custld字段上的全局索引，保留Acptld，Cusfidl上的分区索引，再进行数据插入耗时情况参见表2： 表2　仅存在分区索引时插入数据的耗时 删除该表上所有三个索引后，再进行数据插入的耗时情况参见表3：表3　不存在索引时插入数据的耗时 2　索引对数据插入的影响 (1)存在全局索引，数据插入的时间随分区数的增加而增加从表1中可以看出，在2006年1月至2006年12月期间，存在CustId的全局索引，随着数据量的增长，每新增一个月的数据，耗时需要 多增加1000秒左右。从表2中可以看出，在删除了CustId的全局索引后(此时还存在CustIdl及Acptld的分区索引)每次插入数据的时间维 持在3000秒左右。(2)索引的存在会影响数据插入的速度从表3中可以看出，没有索引时每个分区插入的时间为1200秒左右，比存在索引时插入的速度快一倍多。这说明并非索引越多性能越好，是否建立列索引需根据具体应用决定。(3)如果被索引的列的值与原来的数据相同，会影响插入的性能插入第二个月的数据时，对于B树索引，不同月份同一CustId的索引数据存放在一起，这需要更多的资源去维护索引，索引空间不够时，还需分裂索引块。此时全局索引的表现比分区索引明显得多，因为全局索引中，被索引列中相同的值的重复率会比分区索引高很多。(4)当插入数据量很大时，索引需重新分裂，用更多的数据块来存放索引数据在插入200606月份的数据后，进行查询并跟踪执行语句所扫描的数据块。查询语句为：select Custld,AcptId，Cusfldl，hsUnit,Dept，Unit from DATA_DEST where Custld=1380745518；插入200606月份的数据后查询跟踪的结果如表4所示：表4　插入200606月份的数据后查询跟踪的结果 插入200612月份的数据后查询跟踪的结果如表5所示表5　插入200612月份的数据后查询跟踪的结果 比较表4和表5的黑体部分，可以看到随着相同的值数据插入，索引块出现了迁移。在2006年12月份的时候，同一CustId列数据所在的索 引数据块(数据块编号为：5769587、9462046、5771162、548)与6月份时的索引数据块(数据块编号为：5769587、9462046、5771162、548)是不同的。3　索引对查询性能的影响下面分析有18亿条记录的表在单个分区内、多个分区内及全表内使用索引字段的一些表现。以下的查询均基于CustIdl列来查询。考虑到SGA缓存数据在DATA BUFFER对查询的影响，在每次查询前清空SGA中的数据。(1)单个分区，离散度高的列上的分区索引效率比按高模拟过程中发现，存在B树索引时，离散度高的列(如本文原文Cusfld)索引的效率较高，数据量的增长并未造成索引性能的降低。通过ORADEBUG命令DUMP出Oracle内存中DATABUFFER部分的数据块，发现在一个分区内只需4次分裂，索引就可以定位到需要的数据。测试结果如表6所示。查询语句为：select Custld,Acptld,Custldl,hsUnit,Dept,Unit from DATA_DEST where Custldl=1380745518and FEYM=200610；表6　单个分区内的根据CustId查询的结果 (2)多个分区内使用索引查询的致年没有差异在数据插入过程中单独查询某CustIdl在200610，200710，200810三个年月的数据，可以看出：无论对哪个年月进行查询， 只要指定查询的CustIdl和Feym条件，查询都是对特定的分区进行扫描，消耗很少(此例中耗时为00：00：00．31)。(3)全表所有分区的索引扫描尽管效率按高，但由于要扫描所有分区，响应时间相对长如果只指定CustIdl条件进行查询，则会搜索该表的全部分区，共返回36条记录，耗时0．85秒。测试结果如表7所示。表7　全表范围索引扫描的输出片断 4　结束语综上所述，可以得出以下结论与建议：(1)对于大表(记录超过1亿条)采用Oracle提供的分区特性就可以满足大数据量下的系统性能要求，不必为每个业务单位单独建立一张物理表；(2)在每个分区5000万条记录的情况下，分区范围内的查询效率较低。对于像CustId这样的在每个分区中离散度都高的列，建议建成分区索引，以保证系统的可维护性以及性能的稳定，并在SQL中尽可能限制查询所需要涉及到的表分区。(3)如果不是主键列，而且DML语句中多数情况下可以使用分区列作为数据操作条件，则建议建立分区索引。(4)如果使用分区，分区策略需要根据实际业务需要来确定。比如如果经常按业务单位进行DML操