1、搜尋的索引列：最適合索引的列是出現在where子句中的列，或連結子句中指定的列，而不是出現在select關鍵詞後的選擇列表中的列
2、使用唯一索引：考慮列中值的分佈。索引的列基礎越大，索引的效果越好。列如記錄性別的列，不管搜尋那個性別，都會得出大約一般的行，因此對此列索引沒有太大的作用
3、使用短索引：如果對字串列進行索引，應該制定一個字首長度，只要有可能就儘量這樣做。例如，有一個CHAR(200)列，如果在前10個或者20個字元進行索引能夠節省大量索引空間，也可能會使查詢更快。較小的索引涉及的磁碟IO較小，較短的值比較起來更快。更重要的是，對於較短的鍵值，索引快取記憶體中能夠容納更多的鍵值，因此MySQL也可以在記憶體中容納更多的值。這樣就增加了找到索引行而不用讀取索引中較多塊的可能性。
4、利用最左字首。建立一個n列的索引時，實際是建立了MySQL可利用的n個索引。多列索引可起幾個索引的作用，因為可以利用索引中最左邊的列集來匹配行。這樣的列整合為最左字首
5、不要過度索引。不要以為索引"越多越好"，什麼東西都用索引是錯誤的。每個額外的索引都要佔用額外的磁碟空間，並降低寫操作的效能。在修改表的內容時，索引必定進行更新，有時可能需要重構，因此，索引越多，所花的時間越長。如果一個索引很少使用或從不使用，那也會不必要的減緩表的修改速度。此外，MySQL在生成一個執行計劃時，需要考慮各個索引，這也要花費時間。建立多餘的索引給查詢優化帶來了更多的工作。索引太多也可能會使MySQL選擇不到所要使用的最好索引。只保持所需的索引有利於查詢優化
6、對於InnoDB儲存引擎的表，記錄預設會按照一定的順序儲存，如果有明確定義的主鍵，則會按照主鍵順序儲存。如果沒有主鍵，但有唯一索引，那麼就會按照唯一索引的順序儲存。如果既沒有主鍵又沒有唯一索引，那麼表中會自動生成一個內部列，按照這個列的順序儲存。按照主鍵或者內部列的順序進行訪問的速度是最快的，索引InnoDB表儘量自己指定主鍵，當表中同時有幾列都是唯一的，都可以作為主鍵的時候，要選擇最常最為訪問條件的列作為主鍵，提高查詢的效率。另外，還需要注意，InnoDB表的普通索引都會儲存主鍵的鍵值，所以主鍵要儘可能選擇較短的資料型別，可以有效地減少索引的磁碟佔用，提高索引的快取效果
Hash 索引結構的特殊性，其檢索效率非常高，索引的檢索可以一次定位，不像B-Tree索引需要從根節點到枝節點，最後才能訪問到頁節點這樣多次的IO訪問，所以 Hash 索引的查詢效率要遠高於 B-Tree索引
1)Hash索引僅僅能滿足"=","IN"和"<=>"查詢，不能使用範圍查詢。
由於 Hash 索引比較的是進行 Hash 運算之後的 Hash值，所以它只能用於等值的過濾，不能用於基於範圍的過濾，因為經過相應的 Hash演算法處理之後的 Hash 值的大小關係，並不能保證和Hash運算前完全一樣。
2)Hash 索引無法被用來避免資料的排序操作。
由於 Hash 索引中存放的是經過 Hash 計算之後的 Hash值，而且Hash值的大小關係並不一定和 Hash運算前的鍵值完全一樣，所以資料庫無法利用索引的資料來避免任何排序運算；
3)Hash索引不能利用部分索引鍵查詢。
對於組合索引，Hash 索引在計算 Hash 值的時候是組合索引鍵合併後再一起計算 Hash 值，而不是單獨計算 Hash值，所以通過組合索引的前面一個或幾個索引鍵進行查詢的時候，Hash 索引也無法被利用。
4)Hash索引在任何時候都不能避免表掃描。
前面已經知道，Hash 索引是將索引鍵通過 Hash 運算之後，將 Hash運算結果的 Hash值和所對應的行指標資訊存放於一個 Hash 表中，由於不同索引鍵存在相同 Hash 值，所以即使取滿足某個 Hash 鍵值的資料的記錄條數，也無法從 Hash索引中直接完成查詢，還是要通過訪問表中的實際資料進行相應的比較，並得到相應的結果。
5)Hash索引遇到大量Hash值相等的情況後效能並不一定就會比B-Tree索引高
對於選擇性比較低的索引鍵，如果建立 Hash 索引，那麼將會存在大量記錄指標資訊存於同一個 Hash 值相關聯。這樣要定位某一條記錄時就會非常麻煩，會浪費多次表資料的訪問，而造成整體效能