首先明白為什麼索引會增加速度，db在執行一條sql語句的時候，預設的方式是根據搜尋條件進行全表掃瞄，遇到匹配條件的就加入搜尋結果集合。如果我們對某一欄位增加索引，查詢時就會先去索引列表中一次定位到特定值的行數，大大減少遍歷匹配的行數，所以能明顯增加查詢的速度。那麼在任何時候都應該加索引麼？這裡有幾個反例：1、如果每次都需要取到所有表記錄，無論如何都必須進行全表掃瞄了，那麼是否加索引也沒有意義了。2、對非唯一的字段，例如「性別」這種大量重複值的字段，增加索引也沒有什麼意義。3、對於記錄比較少的表，增加索引不會帶來速度的優化反而浪費了儲存空間，因為索引是需要儲存空間的，而且有個致命缺點是對於update/insert/delete的每次執行，欄位的索引都必須重新計算更新。
那麼在什麼時候適合加上索引呢？我們看乙個mysql手冊中舉的例子，這裡有一條sql語句：
select c.companyid, c.companyname from companies c, user u where c.companyid = u.fk_companyid and c.numemployees >= 0 and c.companyname like '%i%' and u.groupid in (select g.groupid from groups g where g.grouplabel = 'executive')
這條語句涉及3個表的聯接，並且包括了許多搜尋條件比如大小比較，like匹配等。在沒有索引的情況下mysql需要執行的掃瞄行數是 77721876行。而我們通過在companyid和grouplabel兩個欄位上加上索引之後，掃瞄的行數隻需要134行。在mysql中可以通過 explain select來檢視掃瞄次數。可以看出來在這種聯表和複雜搜尋條件的情況下，索引帶來的效能提公升遠比它所佔據的磁碟空間要重要得多。
那麼索引是如何實現的呢？大多數db廠商實現索引都是基於一種資料結構——b樹。因為b樹的特點就是適合在磁碟等直接儲存裝置上組織動態查詢表。b樹的定義是這樣的：一棵m(m>=3)階的b樹是滿足下列條件的m叉樹：
1、每個結點包括如下作用域(j, p0, k1, p1, k2, p2, ... ki, pi) 其中j是關鍵字個數，p是孩子指標
2、所有葉子結點在同一層上，層數等於樹高h
3、每個非根結點包含的關鍵字個數滿足[m/2-1]<=j<=m-1
4、若樹非空，則根至少有1個關鍵字，若根非葉子，則至少有2棵子樹，至多有m棵子樹
看乙個b樹的例子，針對26個英文本母的b樹可以這樣構造：
基本概念介紹：
索引使用索引可快速訪問資料庫表中的特定資訊。索引是對資料庫表中一列或多列的值進行排序的一種結構，例如 employee 表的姓（lname）列。如果要按姓查詢特定職員，與必須搜尋表中的所有行相比，索引會幫助您更快地獲得該資訊。
索引提供指向儲存在表的指定列中的資料值的指標，然後根據您指定的排序順序對這些指標排序。資料庫使用索引的方式與您使用書籍中的索引的方式很相似：它搜尋索引以找到特定值，然後順指標找到包含該值的行。
在資料庫關係圖中，您可以在選定表的「索引/鍵」屬性頁中建立、編輯或刪除每個索引型別。當儲存索引所附加到的表，或儲存該錶所在的關係圖時，索引將儲存在資料庫中。有關詳細資訊，請參見建立索引。
注意;並非所有的資料庫都以相同的方式使用索引。有關更多資訊，請參見資料庫伺服器注意事項，或者查閱資料庫文件。
作為通用規則，只有當經常查詢索引列中的資料時，才需要在表上建立索引。索引占用磁碟空間，並且降低新增、刪除和更新行的速度。在多數情況下，索引用於資料檢索的速度優勢大大超過它的。
索引列可以基於資料庫表中的單列或多列建立索引。多列索引使您可以區分其中一列可能有相同值的行。
如果經常同時搜尋兩列或多列或按兩列或多列排序時，索引也很有幫助。例如，如果經常在同一查詢中為姓和名兩列設定判據，那麼在這兩列上建立多列索引將很有意義。
確定索引的有效性：
索引型別
根據資料庫的功能，可以在資料庫設計器中建立三種索引：唯一索引、主鍵索引和聚集索引。有關資料庫所支援的索引功能的詳細資訊，請參見資料庫文件。
儘管唯一索引有助於定位資訊，但為獲得最佳效能結果，建議改用主鍵或唯一約束。
唯一索引是不允許其中任何兩行具有相同索引值的索引。
當現有資料中存在重複的鍵值時，大多數資料庫不允許將新建立的唯一索引與表一起儲存。資料庫還可能防止新增將在表中建立重複鍵值的新資料。例如，如果在 employee 表中職員的姓 (lname) 上建立了唯一索引，則任何兩個員工都不能同姓。
主鍵索引
資料庫表經常有一列或列組合，其值唯一標識表中的每一行。該列稱為表的主鍵。
在資料庫關係圖中為表定義主鍵將自動建立主鍵索引，主鍵索引是唯一索引的特定型別。該索引要求主鍵中的每個值都唯一。當在查詢中使用主鍵索引時，它還允許對資料的快速訪問。
聚集索引
在聚集索引中，表中行的物理順序與鍵值的邏輯（索引）順序相同。乙個表只能包含乙個聚集索引。
如果某索引不是聚集索引，則表中行的物理順序與鍵值的邏輯順序不匹配。與非聚集索引相比，聚集索引通常提供更快的資料訪問速度。
建立方式和注意事項
接著，來個稍微複雜一點的，如果有個order by字句呢？不管你信不信，大多數的資料庫在使用order by的時候，都將會從索引中受益。
select * from mytable
where category_id=1 and user_id=2
order by adddate desc;
很簡單，就象為where字句中的字段建立乙個索引一樣，也為order by的字句中的字段建立乙個索引：
create index mytable_categoryid_userid_adddate
on mytable (category_id,user_id,adddate);
注意: "mytable_categoryid_userid_adddate" 將會被截短為
"mytable_categoryid_userid_addda"
create
explain select * from mytable
where category_id=1 and user_id=2
order by adddate desc;
notice: query plan:
sort (cost=2.03..2.03 rows=1 width=16)
-> index scan using mytable_categoryid_userid_addda
on mytable (cost=0.00..2.02 rows=1 width=16)
explain
看看explain的輸出，資料庫多做了乙個我們沒有要求的排序，這下知道效能如何受損了吧，看來我們對於資料庫的自身運作是有點過於樂觀了，那麼，給資料庫多一點提示吧。
為了跳過排序這一步，我們並不需要其它另外的索引，只要將查詢語句稍微改一下。這裡用的是postgres，我們將給該資料庫乙個額外的提示--在 order by語句中，加入where語句中的字段。這只是乙個技術上的處理，並不是必須的，因為實際上在另外兩個欄位上，並不會有任何的排序操作，不過如果加入，postgres將會知道哪些是它應該做的。
explain select * from mytable
where category_id=1 and user_id=2
order by category_id desc,user_id desc,adddate desc;
notice: query plan:
index scan backward using
mytable_categoryid_userid_addda on mytable
(cost=0.00..2.02 rows=1 width=16)
explain
現在使用我們料想的索引了，而且它還挺聰明，知道可以從索引後面開始讀，從而避免了任何的排序。
以上說得細了一點，不過如果你的資料庫非常巨大，並且每日的頁面請求達上百萬算，我想你會獲益良多的。不過，如果你要做更為複雜的查詢呢，例如將多張表結合起來查詢，特別是where限制字句中的字段是來自不止乙個**時，應該怎樣處理呢？我通常都盡量避免這種做法，因為這樣資料庫要將各個表中的東西都結合起來，然後再排除那些不合適的行，搞不好開銷會很大。
如果不能避免，你應該檢視每張要結合起來的表，並且使用以上的策略來建立索引，然後再用explain命令驗證一下是否使用了你料想中的索引。如果是的話，就ok。不是的話，你可能要建立臨時的表來將他們結合在一起，並且使用適當的索引。
要注意的是，建立太多的索引將會影響更新和插入的速度，因為它需要同樣更新每個索引檔案。對於乙個經常需要更新和插入的**，就沒有必要為乙個很少使用的where字句單獨建立索引了，對於比較小的表，排序的開銷不會很大，也沒有必要建立另外的索引。
以上介紹的只是一些十分基本的東西，其實裡面的學問也不少，單憑explain我們是不能判定該方法是否就是最優化的，每個資料庫都有自己的一些優化器，雖然可能還不太完善，但是它們都會在查詢時對比過哪種方式較快，在某些情況下，建立索引的話也未必會快，例如索引放在乙個不連續的儲存空間時，這會增加讀磁碟的負擔，因此，哪個是最優，應該通過實際的使用環境來檢驗。
在剛開始的時候，如果表不大，沒有必要作索引，我的意見是在需要的時候才作索引，也可用一些命令來優化表，例如mysql可用"optimize table"。
Mysql 索引問題
行鎖開銷大，鎖表慢，但高併發下相比之下效能更高 因為範圍小，影響範圍小，衝突概率小 表鎖雖然開銷小，鎖表快，但高併發下效能低 一句話一刀切，速度快，影響範圍大，更易衝突導致等待 innodb只有在通過索引條件檢索資料時使用行級鎖，否則使用表鎖 innodb的行鎖是 針對索引加的鎖 不是針對記錄加的鎖...
MySQL索引的索引長度問題
mysql索引的索引長度問題 specified key was too long max key length is 1000 bytes.一 修改mysql的預設儲存引擎 1 檢視mysql儲存引擎命令，在mysql 提示符下搞入show engines 字段 support為 default表...
MySQL索引的索引長度問題
mysql的每個單錶中所建立的索引長度是有限制的,且對不同儲存引擎下的表有不同的限制。在myisam表中，建立組合索引時，建立的索引長度不能超過1000，注意這裡索引的長度的計算是根據表字段設定的長度來標量的，例如 create table test id int,name1 varchar 300...