個人想法：所謂的索引優化無非就是引擎、索引類型的選擇，索引順序的排列，索引排序的理解！
1)我會首先考慮採用哪種存儲引擎：INNODB 、MYISAM 、ARCHIVE 、MEMORY，因爲索引是在引擎層實現的。
2)接下來考慮應該採用哪種索引：B-TREE 和HASH索引，B-TREE更適合範圍查詢，HASH更適合精確查詢。
3)利用好EXPLAIN 工具分析查詢語句:EXPLAIN select * from 表名 ；
注意rows項和以及type項，分別表示了查詢了多少行，以及查詢表的方式。
4)創建索引時列的順序,經驗選擇法則不考慮排序與分組時推薦將選擇性高的前綴放在索引列順序的前面
計算完整列的選擇性：不重複索引列的前綴和數據表記錄總數的比值。推薦—> 【0.0310】
示例1：select count(distinct LEFT(列名,3))/count(*) as col_3,count(distinct LEFT(列名,4))/count(*) as col_4,
count(distinct LEFT(列名,5)/count(*))as col_5,count(distinct LEFT(列名,6))/count(*)as col_6
FROM 表名；
解析：通過對不同前綴長度計算來記錄選擇性，推薦值接近0.0310的前綴長度作爲前綴索引；
5)聚簇索引 ：存儲數據的方式而非一種單獨的索引類型
推薦主鍵自增AUTO_INCREMENT，它確保了insert數據存儲的連續性，主鍵頁被順序的記錄填滿；
如果未使用自增AUTO_increment，在進行數據insert操作時會造成隨機I/O，innodb引擎不得不頻繁的做頁分裂操作以插入數據，造成了大量的碎片；
6)覆蓋索引 ：一個索引包含所查詢字段的值，覆蓋索引必須存儲索引咧的值，所以只有B-TREE索引符合，並且需要考慮引擎momery不支持覆蓋索引；
7)索引排序 ： 設（col1，col2，col3，col4，col5） 索引列順序是（col1,col3,col5）
壹）where col1=‘常量’ order by col3，col5 \G 雖然order by 不滿足索引醉左前綴，但是col1是常量；組合成功
貳）where col1=‘常量’ order by col3 desc \G 兩列組合排序；
叄）where col1>‘常量’ order by col3，col5 \G 依然成立因爲它符合索引的順序