轉載自：http://hi.baidu.com/lzpsky/item/899e7df5498c66ce521c262b
索引分為聚簇索引和非聚簇索引。
以一本英文課本為例，要找第8課蚪腐，直接翻書，若先翻到第5課，則往后翻，再翻到第10課逗宜，則又往前翻。這本書本身就是一個索引空骚，即“聚簇索引”纺讲。
如果要找"fire”這個單詞，會翻到書后面的附錄囤屹，這個附錄是按字母排序的熬甚，找到F字母那一塊，再找到"fire”肋坚，對應的會是它在第幾課乡括。這個附錄，為“非聚簇索引”智厌。
由此可見诲泌，聚簇索引，索引的順序就是數(shù)據(jù)存放的順序铣鹏，所以敷扫，很容易理解，一張數(shù)據(jù)表只能有一個聚簇索引诚卸。
聚簇索引要比非聚簇索引查詢效率高很多葵第，特別是范圍查詢的時候。所以惨险，至于聚簇索引到底應該為主鍵羹幸，還是其他字段脊髓，這個可以再討論辫愉。
1、MYSQL的索引
mysql中将硝，不同的存儲引擎對索引的實現(xiàn)方式不同恭朗，大致說下MyISAM和InnoDB兩種存儲引擎。
MyISAM的B+Tree的葉子節(jié)點上的data依疼，并不是數(shù)據(jù)本身痰腮，而是數(shù)據(jù)存放的地址。主索引和輔助索引沒啥區(qū)別律罢，只是主索引中的key一定得是唯一的膀值。這里的索引都是非聚簇索引棍丐。
MyISAM還采用壓縮機制存儲索引，比如沧踏，第一個索引為“her”歌逢，第二個索引為“here”，那么第二個索引會被存儲為“3,e”翘狱，這樣的缺點是同一個節(jié)點中的索引只能采用順序查找秘案。
InnoDB 的數(shù)據(jù)文件本身就是索引文件，B+Tree的葉子節(jié)點上的data就是數(shù)據(jù)本身潦匈，key為主鍵阱高，這是聚簇索引。非聚簇索引茬缩，葉子節(jié)點上的data是主鍵 (所以聚簇索引的key赤惊，不能過長)。為什么存放的主鍵凰锡，而不是記錄所在地址呢荐捻，理由相當簡單，因為記錄所在地址并不能保證一定不會變寡夹，但主鍵可以保證处面。
至于為什么主鍵通常建議使用自增id呢？
2菩掏、聚簇索引
聚 簇索引的數(shù)據(jù)的物理存放順序與索引順序是一致的魂角，即：只要索引是相鄰的，那么對應的數(shù)據(jù)一定也是相鄰地存放在磁盤上的智绸。如果主鍵不是自增id野揪，那么可以想 象，它會干些什么瞧栗，不斷地調(diào)整數(shù)據(jù)的物理地址斯稳、分頁，當然也有其他一些措施來減少這些操作迹恐，但卻無法徹底避免挣惰。但，如果是自增的殴边，那就簡單了憎茂，它只需要一 頁一頁地寫，索引結構相對緊湊锤岸，磁盤碎片少竖幔，效率也高。
聚簇索引不但在檢索上可以大大滴提高效率是偷，在數(shù)據(jù)讀取上也一樣拳氢。比如：需要查詢f~t的所有單詞募逞。
一個使用MyISAM的主索引，一個使用InnoDB的聚簇索引馋评。兩種索引的B+Tree檢索時間一樣凡辱，但讀取時卻有了差異。
因為MyISAM的主索引并非聚簇索引栗恩，那么他的數(shù)據(jù)的物理地址必然是凌亂的透乾，拿到這些物理地址，按照合適的算法進行I/O讀取磕秤，于是開始不停的尋道不停的旋轉乳乌。聚簇索引則只需一次I/O。
不過市咆，如果涉及到大數(shù)據(jù)量的排序汉操、全表掃描、count之類的操作的話蒙兰，還是MyISAM占優(yōu)勢些磷瘤，因為索引所占空間小，這些操作是需要在內(nèi)存中完成的搜变。
鑒于聚簇索引的范圍查詢效率采缚，很多人認為使用主鍵作為聚簇索引太多浪費，畢竟幾乎不會使用主鍵進行范圍查詢挠他。但若再考慮到聚簇索引的存儲扳抽，就不好定論了。
