一. mysql的索引
mysql中，不同的儲存引擎對索引的實現方式不同，大致說下myisam和innodb兩種儲存引擎。
myisam的b+tree的葉子節點上的data，並不是資料本身，而是資料存放的位址。主索引和輔助索引沒啥區別，只是主索引中的key一定得是唯一的。這裡的索引都是非聚簇索引。
myisam還採用壓縮機制儲存索引，比如，第乙個索引為「her」，第二個索引為「here」，那麼第二個索引會被儲存為「3,e」，這樣的缺點是同乙個節點中的索引只能採用順序查詢。
innodb的資料檔案本身就是索引檔案，b+tree的葉子節點上的data就是資料本身，key為主鍵，這是聚簇索引。非聚簇索引，葉子節點上的data是主鍵(所以聚簇索引的key，不能過長)。為什麼存放的主鍵，而不是記錄所在位址呢，理由相當簡單，因為記錄所在位址並不能保證一定不會變，但主鍵可以保證。
至於為什麼主鍵通常建議使用自增id呢？
我們可以這麼理解聚簇索引：索引的葉節點就是資料節點。而非聚簇索引的葉節點仍然是索引節點，只不過有乙個指標指向對應的資料塊。
二. 聚簇索引
聚簇索引的資料的物理存放順序與索引順序是一致的，即：只要索引是相鄰的，那麼對應的資料一定也是相鄰地存放在磁碟上的。如果主鍵不是自增id，那麼可以想象，它會幹些什麼，不斷地調整資料的實體地址、分頁，當然也有其他一些措施來減少這些操作，但卻無法徹底避免。但，如果是自增的，那就簡單了，它只需要一頁一頁地寫，索引結構相對緊湊，磁碟碎片少，效率也高。
聚簇索引不但在檢索上可以大大滴提高效率，在資料讀取上也一樣。比如：需要查詢f~t的所有單詞。
乙個使用myisam的主索引，乙個使用innodb的聚簇索引。兩種索引的b+tree檢索時間一樣，但讀取時卻有了差異。
因為myisam的主索引並非聚簇索引，那麼他的資料的實體地址必然是凌亂的，拿到這些實體地址，按照合適的演算法進行i/o讀取，於是開始不停的尋道不停的旋轉。聚簇索引則只需一次i/o。
不過，如果涉及到大資料量的排序、全表掃瞄、count之類的操作的話，還是myisam佔優勢些，因為索引所佔空間小，這些操作是需要在記憶體中完成的。
鑑於聚簇索引的範圍查詢效率，很多人認為使用主鍵作為聚簇索引太多浪費，畢竟幾乎不會使用主鍵進行範圍查詢。但若再考慮到聚簇索引的儲存，就不好定論了。
聚集索引和非聚集索引區別
聚集索引 資料行的物理順序與列值 一般是主鍵那一列 的邏輯順序相同，乙個表只能擁有乙個聚集索引！非聚集索引 該索引中索引的邏輯順序與磁碟上行的物理順序不同乙個表可以擁有多個非聚集索引！非聚集索引可細分成普通索引，唯一索引，全文索引 區別 聚集索引 可以幫助把很大的範圍，迅速減小範圍。但是查詢該記錄，...
聚集索引和非聚集索引的區別
暫且摘錄如下 摘錄1 前者加在不常更新的表，後者加在經常更新的表 摘錄2 使用聚集索引 聚集索引確定表中資料的物理順序。聚集索引類似於 簿，後者按姓氏排列資料。由於聚集索引規定資料在表中的物理儲存順序，因此乙個表只能包含乙個聚集索引。但該索引可以包含多個列 組合索引 就像 簿按姓氏和名字進行組織一樣...
聚集索引和非聚集索引的區別
聚集索引和非聚集索引的區別 漢語字典的正文本身就是乙個聚集索引。比如，我們要查 安 字，就會很自然地翻開字典的前幾頁，因為 安 的拼音是 an 而按照拼音排序漢字的字典是以英文本母 a 開頭並以 z 結尾的，那麼 安 字就自然地排在字典的前部。如果您翻完了所有以 a 開頭的部分仍然找不到這個字，那麼...