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

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

  1. 1、本文档共7页,可阅读全部内容。
  2. 2、有哪些信誉好的足球投注网站(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  5. 5、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  6. 6、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  7. 7、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  8. 8、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
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(聚簇因子)来记录和指示表中行相对于索引的有序程度,优化器会据此和其它一些条件来选择使用索引还是使用全表扫描。   那么创建索引是否宁滥勿缺?绝对不是,我们来看看索引过多的不利影响:   ①索引

文档评论(0)

gmomo-lt + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档