有人說乙個表的索引不能超過6個，這是不對的。衡量索引是否合理不能單純的用乙個數字來判斷。在
一張表上建立多少索引，建立什麼樣的索引，並無一定的規律。不能說一張表上有6個索引，就不能再建立第
7個索引了。設計索引時應該從應用的角度出發，
一切服從應用需要。
大家都知道索引會增加維護的成本，影響dml語句的效能，但在一般的oltp系統中，和dml操作相
比，select操作所佔的比例要少的多。如果少乙個索引，可能導致某張大表經常進行全表掃瞄，增加的
cpu和i/o開銷可能達到這個索引維護成本的上百倍。所以不能單獨的憑乙個數字來判斷索引是否合理。
分析索引是否合理，需要將sql都找出來，按照 buffer get或者physical read 排序，分析排在前面對性
能影響較大的sql，看where 條件和連線條件，然後判斷如何建立索引。
設計索引時要統籌考慮
在設計時，必須為執行最為頻繁，對系統效能影響較大的sql設計成本開銷最小的索引，而一些次要的
sql，可以和其他sql共用索引（建立復合索引來共用），這些索引可能並不是最優的，但能滿足目前應用
的需求。
要記住，最優的並不是最好
的，最適合的才是最好的。
盡可能的讓乙個索引為更多的sql服務，設計合理的復合索引是十分關鍵的。
適當的時候需要建立符合索引
有這樣乙個sql：
select * from table where a > *** and b > ***
在a列上有乙個索引，但該sql在執行時發現通過a的索引篩選出來的有4000條資料，然後通過篩選出
最後的結果是10條。既然建乙個復合索引（a+b），可以減少400倍的資料讀取，為什麼不呢？
合併類似索引
比如乙個表上有a + b和 a+c 兩個索引，設計乙個a+b+c索引也許是不錯的選擇。
比如有a + b+c和 a+c +b兩個索引，設計乙個a+b+c索引或者a+c +b索引即可，至於設計成 a+b+c
還是a+c +b取決於是a + b用的多，還是a+c作為篩選條件時用的多。
比如a+ c+e和a+b+e => 可以設計成a+ c+b+e或其他的，
要注意的是，具體字段順序，要根據應用情
況取捨。
盡可能將復合索引中選擇性強的字段放前面，這樣可以減少索引範圍掃瞄成本。
根據實際情況選擇索引類別
位圖索引和b樹索引的使用場合是不同的，位圖索引儲存的是字段值的點陣圖，當修改索引的字段的值
時，會鎖定和這個值相等的所有記錄。因此，一般來說，某張表如果針對索引列更新、刪除、插入比較頻
繁，是不適合使用位圖索引的，不然很容易出現死鎖。一般來說otlp中不適合使用位圖索引。但如果不出現
死鎖或鎖增加的情況，在otlp系統中使用位圖索引也是可以的。
要注意函式索引的使用
函式索引和普通索引的維護開銷是差不多的。如果系統中不可避免的在某列上使用函式，那麼請放心的
使用函式索引吧。
有時候在索引中增加部分額外的字段能起到很好的作用。
例如：
select a from table where b=：1
對於這樣的sql，一般會建立b列的索引。但如果建立乙個a+b的索引，可以避免對錶的掃瞄。當然，
這裡不是說碰到這樣的情況就建立包含select中的列的索引，應該根據實際情況來設計。
盡信書不如無
書。使用索引時要注意的：
第一：索引必須是有用的。
不使用的索引會增加dml操作的成本，也可能導致錯誤的執行計畫。所以必須清除無用的索引，但要注
意的是，除非有很大的把握，否則不要輕易刪除索引。在刪除索引時，要確認沒有業務會使用到它。
第二，確保表和索引的統計資訊的一致性。
如果索引的統計資訊和表的統計資訊不一致，可能會出現錯誤的執行計畫。對索引分析後，需要對錶重
新分析。確保表和索引的統計資訊是一致的。
第三，不要在索引列上使用函式。
在索引列上使用函式，會導致索引失效。所以不要在索引列上使用函式。當然，如果確實要使用，可以
建立函式索引。
另外，避免索引列上使用隱式的強制轉換。比如，索引列a的字段型別為date。當和它比較的值是
timestamp型別時
where create_date > ***
會將小型別向大型別轉換。這時create_date 會被隱式強轉成timestamp型別。變成
where to_ timestamp (create_date)> ***
導致不能使用索引。
php 如何設計索引 關於索引設計的詳細介紹
今天乙個朋友向我諮詢怎麼去優化 mysql，我按著思維整理了一下，大概粗的可以分為21個方向。還有一些細節東西 table cache,表設計，索引設計，程式端快取之類的 先不列了，對乙個系統，初期能把下面做完也是乙個不錯的系統。1.要確保有足夠的記憶體 資料庫能夠高效的執行，最關建的因素需要記憶體...
mysql索引設計 MySQL索引設計原則
一 mysql常用的索引型別 1.1主鍵索引 primary key 1.2唯一索引 unique 1.3普通索引 index 1.4全文索引 1.5組合索引 二 mysql常用的資料結構 2.1b tree 2.2雜湊索引 三 索引的設計原則 3.1選擇唯一性索引 被設為唯一性的值可以設定為索引，...
索引 聚集索引設計指南
每個表只能有乙個聚集索引,因為資料行本身只能按乙個順序儲存.有關聚集索引體系結構的詳細資訊,請參閱 聚集索引結構.每個表幾乎都對列定義聚集索引來實現下列功能 uniqueifieruniqueifier 查詢注意事項 在建立聚集索引之前,應先了解資料是如何被訪問的.考慮對具有以下特點的查詢使用聚集索...