(08)DBA写给开发的索引经验

      索引可是个大事情,翻开任意一本数据库调优的书,索引都会占到比较大的篇幅。这是个人人都很重视的问题,可往往起始阶段还好,但数据库到最后常常还是会陷入由索引起的性能怪圈中。特别是在上线运行过一段时间的系统上表现特别明显. 人们为了提高查询速度,或者说自认为可以提高速度。所以不停的向上面加索引,改索引,加索引。极端的甚至每个字段都建或者是一个有什么查询就建个索引先,种种乱象大把。由此产生太多的无效索引,占用大量系统空间,拖慢相关表的写入性能,增加系统的waits.由此引发一堆的问题 。
      造成这些往往是开发不会正确的建索引。其实有DBA参与的项目有时也会出现由索引引起的问题,更别说很多项目是没有DBA参与或后期没有DBA了,直到数据库出现严重问题. 
       索引这东西太值得深入研究了,网上有很多很多DBA对它们做各类测试和研究。数据库每次发新版本,也会对这个特性更新点新东西。不过那都离开发稍有点远。我在这只想介绍一些有用的方法给开发,让他们可以放心的在项目享受索引的魔力,而不用太担心被它所伤。
     先声明一点,调优没那么简单,水深得很。我在这只说些通常情况下我认为大致可行的办法,并不适合所有情况。

    就索引而言,先要明白几个概念:
         索引不是一定能提高性能的。        
         索引也不是越多越好。
         索引本身也是占用空间,牺牲表的写入性能。 
    具体为什么我就不在这占地方写了,大把的文章说这些。 

你加索引时只要知道这几点:
 1.找到说服自己的理由
    在确定要加索引时,首先要搞明白是确实碰到性能问题了,查询要花很多时间?
    还是因为很多SQL的WHERE条或关联需用到这个?
     如果不是这两种情况,那就要再思考一下了。
 2. 多尝试,找出最合适的索引组合。
    你确定要加索引了。现在有几个问题,
      a. WHERE 条件用到表的两个字段,那到底是分别建两个单键索引还是合在一起建一个复合索引? 
      b.或者说,其中一个列已有建一个索引,那我还需要建个复合索引吗?  
      下决定前,你要清楚它们各自的优势在哪。
          查询特定的列的记录,单索引肯定比复合索引快,至于快多少,那很难有个定量的。要靠实际环境的测试。
         复合索引组合对这个同时使用了两个字段的情况肯定提速要明显,而且原来使用了单索引的其它SQL,照样能
         享受到索引的福利。不过复合索引字段多,占的空间相对要大,查询时访问的数据块也要多,消耗的资源也大。
         总之两者各有千秋。 
       你要评估下哪种WHERE条件和连接条件用得比较多,哪些SQL的优先级比较高,有条件最好再实际测试一下速度。
   3. 具体选择什么类型的索引?
 数据库的索引种类非常之多,不要一知半解去玩,很多就玩出问题了,我后面会具体另外花时间写写这个。我在这
只建议就用默认建立的那种索引好了, 其它索引你要确定搞清楚了再用。
   4. 索引增加或重建操作要小心
          别想当然的去直接操作,其实可不简单有注意事项的。
       a. 操作前要做好检查。
            做过Oracle表设计的都知道一个潜规则,通常会把数据表空间和索引表空间分开,以减少磁盘I/O竞争和便于管理。
            但这说明了一个问题,索引确确实实是占空间的,那你建索引前尤其是大表,最好评估下索引表空间是否够。
       b. 操作要看时机。
           对于已上线的系统,不到万不得已,尽量尽量不要在业务高峰期操作,尤其是对大表。会消耗掉大量的系统资源。
        并引发不可料的问题。 实际上好多库出问题就出在这种操作上,听我一句劝,不要自己给自己找麻烦。
        
 上面说的是加索引的情况,如果你现在的数据库已经是一团乱麻了,你也分不清这些个索引到底有用没。
     可以看看我下面的方法。
           
 
 
    1. 有事没事从em或数据库视图中找出消耗性能最多的SQL,
         找出来,把表关系,表相关的索引拿出来细细分析,确定其合理性。
    2. 从视图中查出索引最多的相关表,看看相关的SQL,是否真需要那么多索引。
    3. 通过索引监控,找出无用的索引.将其去掉.
       对索引做监控时,监控的周期要注意. 有些索引如仓库盘点表上的索引.
       被调用的时隔很长,如刚好不在你的监控周期以内. 你轻易删除了,到用就要
   手忙脚乱地面对由此引起的性能问题. 所以删除时一定要对业务有了解.确认过后再处理.

   对于如何确定一个索引,到底有用还是没用可以采用下面的小技巧.

    (再强调下,具体操作命令别在业务高峰期玩
            11g前,
      先将索引更改为unusable状态,让删除不需要与表数据同步更新.
      如过了比较长的周期,确认这个是没用的,再将其删除就很保险了.
      万一要重新使用时,只需要用rebuild重建,并更新一下统计信息即可.
      不过,如果索引刚好在一张大表上.这个动作要花的时间可能就会很长.
            11g及以后
             可用索引不可见.(Index Invisible)这个新特性。让数据库的优化器彻底无视这个索引。
        而这个索引并没有被删除,也同样会与表做同步更新。这意味着,你确定还需要这索引时,
        只要用命令重新让它们可见就好了。无需再去做索引的重建动作了。

     通过上面的这些操作,坚持下去,细水长流,数据库的性能自然会上去。由索引引起的问题也会少很多的。
    
     上面纯是口水文,说到具体的相关技术点可以自己去查,我以后有时间也会再做补充说明。
 总之希望各自的项目都顺顺利利,稳稳当当,天下大同,世界和平。

MAIL:xcl_168@aliyun.com

原文地址:https://www.cnblogs.com/riasky/p/3458800.html