一、搜索的索引列，不一定是所要選擇的列
換句話說，最適合索引的列是出現在WHERE 子句中的列，或連接子句中指定的列，而不是出現在SELECT 關鍵字後的選擇列表中的列，例如：
SELECT
col_a ←不適合作索引列
FROM
Tbl1 LEFT JOIN tbl2
ON tbl1.col_b = tbl2.col_c ←適合作索引列
WHERE
col_d = expr ←適合作索引列
當然，所選擇的列和用於 WHERE 子句的列也可能是相同的。關鍵是，列出現在選擇列表中不是該列應該索引的標誌。
出現在連接子句中的列或出現在形如 col1 = col2 的表達式中的列是很適合索引的列。查詢中的col_b 和col_c 就是這樣的例子。如果MySQL 能利用連接列來優化一個查詢，
表示它通過消除全表掃描相當可觀地減少了錶行的組合。
二、使用唯一索引
考慮某列中值的分佈。對於惟一值的列，索引的效果最好，而具有多個重複值的列，其索引效果最差。例如，存放年齡的列具有不同值，很容易區分各行。而用來記錄性別的
列，只含有“M”和“F”，則對此列進行索引沒有多大用處（不管搜索哪個值，都會得出大約一半的行）。
三、使用短索引
如果對串列進行索引，應該指定一個前綴長度，只要有可能就應該這樣做。例如，如果有一個CHAR(200) 列，如果在前10 個或20 個字符內，多數值是惟一的，那麼就不要對
整個列進行索引。對前10 個或20 個字符進行索引能夠節省大量索引空間，也可能會使查詢更快。較小的索引涉及的磁盤I/O 較少，較短的值比較起來更快。更爲重要的是，對於
較短的鍵值，索引高速緩存中的塊能容納更多的鍵值，因此，MySQL 也可以在內存中容納更多的值。這增加了找到行而不用讀取索引中較多塊的可能性。（當然，應該利用一些常
識。如僅用列值的第一個字符進行索引是不可能有多大好處的，因爲這個索引中不會有許多不同的值。）
四、利用最左前綴
在創建一個n 列的索引時，實際是創建了MySQL 可利用的n 個索引。多列索引可起幾個索引的作用，因爲可利用索引中最左邊的列集來匹配行。這樣的列集稱爲最左前綴。
（這與索引一個列的前綴不同，索引一個列的前綴是利用該的前n 個字符作爲索引值。）
假如一個表在分別名爲state、city 和zip 的三個列上有一個索引。索引中的行是按state/city/zip 的次序存放的，因此，索引中的行也會自動按state/city 的順序和
state 的順序存放。這表示，即使在查詢中只指定state 值或只指定state 和city 的值，MySQL 也可以利用索引。因此，此索引可用來搜索下列的列組合：
MySQL 不能使用不涉及左前綴的搜索。例如，如果按city 或zip 進行搜索，則不能使用該索引。如果要搜索某個州以及某個zip 代碼（索引中的列1和列3），則此索引不
能用於相應值的組合。但是，可利用索引來尋找與該州相符的行，以減少搜索範圍。
五、不要過度索引
不要以爲索引“越多越好”，什麼東西都用索引是錯的。每個額外的索引都要佔用額外的磁盤空間，並降低寫操作的性能，這一點我們前面已經介紹過。在修改表的內容
時，索引必須進行更新，有時可能需要重構，因此，索引越多，所花的時間越長。如果有一個索引很少利用或從不使用，那麼會不必要地減緩表的修改速度。此外，MySQL 在生
成一個執行計劃時，要考慮各個索引，這也要費時間。創建多餘的索引給查詢優化帶來了更多的工作。索引太多，也可能會使MySQL 選擇不到所要使用的最好索引。只保持所需
的索引有利於查詢優化。
如果想給已索引的表增加索引，應該考慮所要增加的索引是否是現有多列索引的最左索引。如果是，則就不要費力去增加這個索引了，因爲已經有了。
六、考慮在列上進行的比較類型
索引可用於“<”、“<=”、“=”、“>=”、“>”和BETWEEN 運算。在模式具有一個直接量前綴時，索引也用於LIKE 運算。如果只將某個列用於其他類型的運算時（如
STRCMP( )），對其進行索引沒有價值。