(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:[e-mail]

Blog:http://blog.csdn.net/xcl168