通俗點講
- 聚簇索引：將數(shù)據(jù)存儲與索引放到了一塊摄职，找到索引也就找到了數(shù)據(jù)
- 非聚簇索引：將數(shù)據(jù)存儲于索引分開結(jié)構(gòu)，索引結(jié)構(gòu)的葉子節(jié)點指向了數(shù)據(jù)的對應(yīng)行损趋，myisam通過key_buffer把索引先緩存到內(nèi)存中恤煞，當(dāng)需要訪問數(shù)據(jù)時（通過索引訪問數(shù)據(jù)），在內(nèi)存中直接搜索索引赡译，然后通過索引找到磁盤相應(yīng)數(shù)據(jù)，這也就是為什么索引不在key buffer命中時模捂，速度慢的原因
澄清一個概念：innodb中捶朵，在聚簇索引之上創(chuàng)建的索引稱之為輔助索引，輔助索引訪問數(shù)據(jù)總是需要二次查找狂男，非聚簇索引都是輔助索引综看，像復(fù)合索引、前綴索引岖食、唯一索引红碑，輔助索引葉子節(jié)點存儲的不再是行的物理位置，而是主鍵值
何時使用聚簇索引與非聚簇索引
聚簇索引具有唯一性
由于聚簇索引是將數(shù)據(jù)跟索引結(jié)構(gòu)放到一塊，因此一個表僅有一個聚簇索引
一個誤區(qū)：把主鍵自動設(shè)為聚簇索引
聚簇索引默認是主鍵析珊，如果表中沒有定義主鍵羡鸥，InnoDB 會選擇一個唯一的非空索引代替。如果沒有這樣的索引忠寻，InnoDB 會隱式定義一個主鍵來作為聚簇索引惧浴。InnoDB 只聚集在同一個頁面中的記錄。包含相鄰健值的頁面可能相距甚遠奕剃。如果你已經(jīng)設(shè)置了主鍵為聚簇索引衷旅，必須先刪除主鍵，然后添加我們想要的聚簇索引纵朋，最后恢復(fù)設(shè)置主鍵即可柿顶。
此時其他索引只能被定義為非聚簇索引。這個是最大的誤區(qū)操软。有的主鍵還是無意義的自動增量字段嘁锯，那樣的話Clustered index對效率的幫助，完全被浪費了聂薪。
剛才說到了家乘，聚簇索引性能最好而且具有唯一性，所以非常珍貴胆建，必須慎重設(shè)置烤低。一般要根據(jù)這個表最常用的SQL查詢方式來進行選擇，某個字段作為聚簇索引笆载，或組合聚簇索引扑馁，這個要看實際情況。
記住我們的最終目的就是在相同結(jié)果集情況下凉驻，盡可能減少邏輯IO腻要。
結(jié)合圖再仔細點看
- InnoDB使用的是聚簇索引，將主鍵組織到一棵B+樹中涝登，而行數(shù)據(jù)就儲存在葉子節(jié)點上雄家，若使用"where id = 14"這樣的條件查找主鍵，則按照B+樹的檢索算法即可查找到對應(yīng)的葉節(jié)點胀滚，之后獲得行數(shù)據(jù)趟济。
- 若對Name列進行條件搜索，則需要兩個步驟：第一步在輔助索引B+樹中檢索Name咽笼，到達其葉子節(jié)點獲取對應(yīng)的主鍵顷编。第二步使用主鍵在主索引B+樹種再執(zhí)行一次B+樹檢索操作，最終到達葉子節(jié)點即可獲取整行數(shù)據(jù)剑刑。（重點在于通過其他鍵需要建立輔助索引）
MyISM使用的是非聚簇索引媳纬，非聚簇索引的兩棵B+樹看上去沒什么不同双肤，節(jié)點的結(jié)構(gòu)完全一致只是存儲的內(nèi)容不同而已，主鍵索引B+樹的節(jié)點存儲了主鍵钮惠，輔助鍵索引B+樹存儲了輔助鍵茅糜。表數(shù)據(jù)存儲在獨立的地方，這兩顆B+樹的葉子節(jié)點都使用一個地址指向真正的表數(shù)據(jù)素挽，對于表數(shù)據(jù)來說蔑赘，這兩個鍵沒有任何差別。由于索引樹是獨立的毁菱，通過輔助鍵檢索無需訪問主鍵的索引樹米死。
聚簇索引的優(yōu)勢
看上去聚簇索引的效率明顯要低于非聚簇索引，因為每次使用輔助索引檢索都要經(jīng)過兩次B+樹查找贮庞，這不是多此一舉嗎？聚簇索引的優(yōu)勢在哪究西？
- 由于行數(shù)據(jù)和葉子節(jié)點存儲在一起窗慎，同一頁中會有多條行數(shù)據(jù)，訪問同一數(shù)據(jù)頁不同行記錄時卤材，已經(jīng)把頁加載到了Buffer中遮斥，再次訪問的時候，會在內(nèi)存中完成訪問扇丛，不必訪問磁盤术吗。這樣主鍵和行數(shù)據(jù)是一起被載入內(nèi)存的，找到葉子節(jié)點就可以立刻將行數(shù)據(jù)返回了帆精，如果按照主鍵Id來組織數(shù)據(jù)较屿，獲得數(shù)據(jù)更快。
- 輔助索引使用主鍵作為"指針"而不是使用地址值作為指針的好處是卓练，減少了當(dāng)出現(xiàn)行移動或者數(shù)據(jù)頁分裂時輔助索引的維護工作隘蝎，使用主鍵值當(dāng)作指針會讓輔助索引占用更多的空間，換來的好處是InnoDB在移動行時無須更新輔助索引中的這個"指針"襟企。也就是說行的位置（實現(xiàn)中通過16K的Page來定位）會隨著數(shù)據(jù)庫里數(shù)據(jù)的修改而發(fā)生變化（前面的B+樹節(jié)點分裂以及Page的分裂）嘱么，使用聚簇索引就可以保證不管這個主鍵B+樹的節(jié)點如何變化，輔助索引樹都不受影響顽悼。
- 聚簇索引適合用在排序的場合曼振，非聚簇索引不適合
- 取出一定范圍數(shù)據(jù)的時候，使用用聚簇索引
- 二級索引需要兩次索引查找蔚龙，而不是一次才能取到數(shù)據(jù)冰评，因為存儲引擎第一次需要通過二級索引找到索引的葉子節(jié)點，從而找到數(shù)據(jù)的主鍵府蛇，然后在聚簇索引中用主鍵再次查找索引集索，再找到數(shù)據(jù)
- 可以把相關(guān)數(shù)據(jù)保存在一起。例如實現(xiàn)電子郵箱時，可以根據(jù)用戶 ID 來聚集數(shù)據(jù)务荆，這樣只需要從磁盤讀取少數(shù)的數(shù)據(jù)頁就能獲取某個用戶的全部郵件妆距。如果沒有使用聚簇索引，則每封郵件都可能導(dǎo)致一次磁盤 I/O函匕。
聚簇索引的劣勢
- 維護索引很昂貴娱据，特別是插入新行或者主鍵被更新導(dǎo)至要分頁(page split)的時候。建議在大量插入新行后盅惜，選在負載較低的時間段中剩，通過OPTIMIZE TABLE優(yōu)化表，因為必須被移動的行數(shù)據(jù)可能造成碎片抒寂。使用獨享表空間可以弱化碎片
- 表因為使用UUId（隨機ID）作為主鍵结啼，使數(shù)據(jù)存儲稀疏，這就會出現(xiàn)聚簇索引有可能有比全表掃面更慢屈芜，
所以建議使用int的auto_increment作為主鍵
主鍵的值是順序的郊愧，所以 InnoDB 把每一條記錄都存儲在上一條記錄的后面。當(dāng)達到頁的最大填充因子時（InnoDB 默認的最大填充因子是頁大小的 15/16井佑，留出部分空間用于以后修改）属铁，下一條記錄就會寫入新的頁中。一旦數(shù)據(jù)按照這種順序的方式加載躬翁，主鍵頁就會近似于被順序的記錄填滿（二級索引頁可能是不一樣的）
- 如果主鍵比較大的話焦蘑，那輔助索引將會變的更大，因為輔助索引的葉子存儲的是主鍵值盒发；過長的主鍵值例嘱，會導(dǎo)致非葉子節(jié)點占用占用更多的物理空間
為什么主鍵通常建議使用自增id
聚簇索引的數(shù)據(jù)的物理存放順序與索引順序是一致的，即：只要索引是相鄰的迹辐，那么對應(yīng)的數(shù)據(jù)一定也是相鄰地存放在磁盤上的蝶防。如果主鍵不是自增id，那么可以想 象明吩，它會干些什么间学，不斷地調(diào)整數(shù)據(jù)的物理地址、分頁印荔，當(dāng)然也有其他一些措施來減少這些操作低葫，但卻無法徹底避免。但仍律，如果是自增的嘿悬，那就簡單了，它只需要一 頁一頁地寫水泉，索引結(jié)構(gòu)相對緊湊善涨，磁盤碎片少窒盐，效率也高。
因為MyISAM的主索引并非聚簇索引钢拧，那么他的數(shù)據(jù)的物理地址必然是凌亂的蟹漓，拿到這些物理地址，按照合適的算法進行I/O讀取源内，于是開始不停的尋道不停的旋轉(zhuǎn)葡粒。聚簇索引則只需一次I/O。（強烈的對比）
不過膜钓，如果涉及到大數(shù)據(jù)量的排序嗽交、全表掃描、count之類的操作的話颂斜，還是MyISAM占優(yōu)勢些夫壁，因為索引所占空間小，這些操作是需要在內(nèi)存中完成的沃疮。
mysql中聚簇索引的設(shè)定
聚簇索引默認是主鍵掌唾，如果表中沒有定義主鍵，InnoDB 會選擇一個唯一的非空索引代替忿磅。如果沒有這樣的索引，InnoDB 會隱式定義一個主鍵來作為聚簇索引凭语。InnoDB 只聚集在同一個頁面中的記錄葱她。包含相鄰健值的頁面可能相距甚遠。
