儘量為用來搜尋，分類或分組的資料列編制索引，不要為作為輸出顯示的資料列編制索引。換句話說，最適合有索引的資料是那些在where字句中出現的資料列，在聯結子句中給出的資料列，或者是在order by 或group by字句中出現的資料列，根據select關鍵字僅出現在輸出資料列清單裡的資料列最好不要有索引：
SELECT
  col_a    <--  not a candidate
        FROM
  tbll LEFT JOIN tbl2
ON  tbll.col_b = tbl2.col_c  <-- candidates
WHERE
         col_d=expr;           <-- a candidate
當然，你顯示的資料列和在WHERE子句中使用的資料列可能會一樣，問題在於輸出資料列表單中出現的資料列本身並不能說明它應該有索引。
      出現在聯結子句中的資料列，或者WHERE子句中col1=col2格式的表示式裡的資料列特別適合用於索引。上面查詢中給出的col_b和col_c就是這樣的列子，如果MYSQL能夠使用相聯結的資料列來優化查詢，它就不會使用全資料表掃描，這樣能刪除掉大量潛在的資料表-資料行組合。
綜合考慮各資料列的維度勢。資料列的“維度”等於它所容納的非重複值得個數。比如說，如果某個資料列裡的值分別是1,3,7,4,7,3.它的維度就是4，資料列的維度越高（維度的最大值等於資料表裡的資料行的個數）。它包含的獨一無二的值就越多。重複的值就越少。索引使用的效果也就越好。舉例來看。如果一個數據列包含許多不同的年齡值，索引將迅速的將資料行區分開來，但是對於記錄性別的資料列，其中只有2個值“M”和“F”，索引恐怕就幫不了你了，如果這2個值出現情況大致一樣多，那麼不管你搜索的是哪一個值，你都會得到半數左右的資料行，在這種情況下，索引或許就根本不能夠使用，因為當查詢優化程式確定出某一個數值在資料表的資料行中出現頻率超過30%時，查詢優化程式通常會跳過索引，而進行全資料表掃描，現如今的優化器更復雜，能夠把其他因素也考慮進來，所以這個百分比已經不再是MySQL決定進行一次掃描而不是使用一個索引的唯一依據了。
對短小的值進行索引。應該儘量選用比較“小”的資料型別，比如說，如果一個MEDIUMINT資料列已足以容納你需要儲存的資料，就不要選用BIGINT,如果你的資料沒有一個比25個字元更長，就不要選用CHAR(100),比較短小的值可以在以下幾個方面提高索引的處理效能
 1）短小的值可以讓比較操作更快地完成，加快索引查詢速度
 2）短小的值可以讓索引的“體積”更小，減少磁碟I/O活動
 3）短小的鍵值意味著鍵快取裡的索引塊可以容納更多的鍵值，讓mysql可以在記憶體裡同時容納更多的鍵，而這將加大在不需要從磁碟讀取更多索引塊的前提下在記憶體裡找到鍵值的概率，對InnoDB儲存引擎而言，因為它使用的是聚集索引，所以讓主鍵儘量短小將更有好處。所謂“聚集索引”（clustered index）是指把資料行和主鍵值集中儲存在一起的情況，其他的索引都是些二級索引-它們儲存著主鍵值和二級索引值，先在二級索引裡找到一個主鍵值，再通過它找到相應的資料行，這意味著主鍵值在每一個二級索引裡都不會重複出現，如果主鍵值比較長的話，就會導致每一個二級索引都將需要佔用更多的儲存空間。
為字串值的字首編索引。假如你要為字串資料列編索引，應當儘可能給出字首長度，例如你有一個char(200)的資料列，大多值的前10個或20個字元都是唯一的，那麼你就用不著為整個資料列編索引，僅僅為前面20個或30個字元編索引可以節省索引中大量空間，而且會使用查詢進行得更快，為較小的值編排索引可以減少磁碟的輸入輸出，加快比較速度，當然你會想繼續使用一些慣常的做法，但只為第一個字元編索引恐怕不行，因為這樣一來索引中將不會有太多的唯一的值
充分利用最左邊的字首 當你建立了一個N個數據列的複合索引時，實際上就建立了mysql能夠使用的n個索引，一個複合索引在工作是就相當於n個索引，因為索引中最左邊的資料列集合能夠用於匹配資料行，這樣的一個集合就稱為“最左邊的字首”（這和為資料列的字首編索引時不同的，它是將資料列的前N個字元或位元組作為索引值）
適合而止，不要建立過多的索引。不要以為索引越多越好，不要為你看到的所有東西都來編排索引，這是一種錯誤的做法，如上所述，每一個多出的索引都要佔據額外的磁碟空間，而且都會影響寫入操作的效能，當你修改了資料表的內容後，索引必須要更新以及重新編排，你使用的索引越多，這個過程佔據的時間就越長，如果你有一個很少使用或從沒有使用過的索引，你就無謂地降低了資料表修改的速度。此外，MySQL在為檢索生產一個執行方案時都要仔細對索引進行推敲，建立多餘的索引對查詢優化程式就加上了更多的工作，而且，當你有太多索引時，MySQL還有可能（當然這只是一種可能）無法選出最好的索引來使用，僅保留你需要的索引可以幫助查詢優化程式來避免造成這樣的錯誤
讓索引的型別和你打算進行得比較操作的型別保持匹配。在建立索引的時候，絕大多數儲存引擎會選擇它們將使用的索引實現
利用“慢查詢”日誌找到效能低劣的查詢