(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