高并发数据库下的索引创建和使用技巧.docVIP

PAGE PAGE 1 高并发数据库下的索引创建和使用技巧 　　摘要：对于高并发高访问的Web应用程序来说，数据库存取瓶颈一直是个令人头疼的问题。特别当程序架构还是建立在单数据库模式上时。本论文主要介绍了通过创建索引的方式对数据库进行优化，重点介绍了B-tree的原理和实现方式，从数据库底层结构出发，阐明了索引对数据库优化的作用，并介绍了索引创建及利用的一些规律和经验，通过对规律的综合运用，达到数据库优化的目的。 　　关键词：高并发B-tree索引 　　0　引言 　　数据库优化有很多的技巧和方法，而建立索引则是其中经常使用的手段。创建索引一般有以下两个目的：维护被索引列的唯一性和提供快速访问表中数据的策略。索引是从数据库中获取数据的最高效方式之一，95%的数据库性能问题都可以采用索引技术得到解决。作为一条规则，通常对逻辑主键使用唯一的成组索引，对系统键（作为存储过程）采用唯一的非成组索引，对任何外键列[字段]采用非成组索引。不过，索引就像是盐，太多了菜就咸了。你得考虑数据库的空间有多大，表如何进行访问，还有这些访问是否主要用作读写，而本文的目的也正是讨论如何通过创建合适的索引来提高数据库的效能。 　　1　原理简介 　　让我们先来看一个案例： 　　Disks：%　tm_actKbps　tpsKb_readKb_wrtn 　　…… 　　hdiskpower84　70.4　1187.3　69.4　3984　1952 　　hdiskpower85　50.4　489.6　30.2　1904　544 　　hdiskpower86　84.4　1801.7　93.2　6512　2496 　　…… 　　hdiskpower101　80.8　1430.5　86.0　6016　1136 　　hdiskpower102　62.2　931.3　56.6　3776　880 　　hdiskpower105　78.8　1388.9　86.6　6416　528 　　…… 　　hdiskpower114　92.6　2406.6　107.0　9824　2208 　　hdiskpower115　88.4　3187.4　104.4　15152　784 　　hdiskpower116　98.2　6730.0　126.8　15280　18368 　　…… 　　hdiskpower120　81.4　867.3　53.8　3616　720 　　hdiskpower121　97.2　2721.6　220.4　6848　6759 　　hdiskpower122　48.6　576.0　34.2　2480　400 　　%　tm_act：磁盘繁忙程度　Kbps：每秒磁盘的数据吞吐量　tps：每秒磁盘I/O请求。 　　在这个系统中： 　　①使用高端存储，底层已经做了优化：多磁盘RAID10，条带化，双4GB光纤通道，存储cache命中率正常。②高配小机，操作系统级已经优化：做了多个PV，aio　server配置已优化。③数据库实例层已经优化：I/O参数已经优化；数据分布较平均，没有出现磁盘间的I/O过于集中的情况。 　　这样的配置，每个磁盘达到几十至上百MB的I/O吞吐量不成问题，为何现实情况是1M左右的吞吐量，磁盘繁忙程度即80%，是为什么？因为没有使用到索引吗？ 　　下面我们再来看一个SQL语句： 　　select　c1，c2，c3　from　t1　where　c4　between　1000　and　2000 　　全表扫描是多块读，即一次I/O读取多个数据块。以ORACLE数据库为例，假设db_file_multiblock_read_count 　　为16，表有3200个数据块，则全表扫描为共需要3200/ 　　16=200次I/O。那是否加大db_file_multiblock_read_ 　　count就可以优化全表扫描了呢？答案是否定的，这个参数不能无限加大，多处有瓶颈限制。 　　现在我们再来看看这句sql： 　　select　c1，c2，c3　from　t1　where　c4=1000 　　假设索引为三层，返回一行数据，数据扫描应该是这样的： 　　①读取c4字段上索引的根数据块。②读取由根指向的下一级——枝数据块。③读取由枝指向的下一级——叶数据块。④处理叶数据块，根据取值找到对应的index　entry，根据rowid读取表的数据块。 　　共四次I/O。 　　根据上面所说的，是否有时查询会因为使用索引反而大大降低性能？一般不会。数据库通过clustering_factory（聚簇因子）来记录和指示表中行相对于索引的有序程度，优化器会据此和其它一些条件来选择使用索引还是使用全表扫描。 　　那么创建索引是否宁滥勿缺？绝对不是，我们来看看索引过多的不利影响： 　　①索引