(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

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