#### **為什么InnoDB表必須有主鍵，并且推薦使用整型的自增主鍵？** 1. 如果設置了主鍵，那么InnoDB會選擇主鍵作為聚集索引，如果沒有顯式定義主鍵，則InnoDB會選擇第一個不包含有NULL值的唯一索引作為主鍵索引、如果也沒有這樣的唯一索引，則InnoDB會選擇內置6字節長的ROWID作為隱含的聚集索引(ROWID隨著行記錄的寫入而主鍵遞增) 2. 如果使用非自增主鍵（如果身份證號或學號等），由于每次插入主鍵的值近似于隨機，因此每次新紀錄都要被插到現有索引頁得中間某個位置，此時MySQL不得不為了將新記錄插到合適位置而移動數據，甚至目標頁面可能已經被回寫到磁盤上而從緩存中清掉，此時又要從磁盤上讀回來，這增加了很多開銷，同時頻繁的移動、分頁操作造成了大量的碎片，得到了不夠緊湊的索引結構，后續不得不通過OPTIMIZE TABLE來重建表并優化填充頁面 #### **MySQL為什么用整型自增作為索引比較好。而UUID作為索引效率比較低？** 聚簇索引的數據的物理存放順序與索引順序是一致的，即：只要索引是相鄰的，那么對應的數據一定也是相鄰地存放在磁盤上的。如果主鍵不是自增id，那么可以想象，它會干些什么，不斷地調整數據的物理地址、分頁，當然也有其他一些措施來減少這些操作，但卻無法徹底避免。但如果是自增的，那就簡單了，它只需要一頁一頁地寫，索引結構相對緊湊，磁盤碎片少，效率也高。 索引存儲在磁盤，而且樹的每個節點分配的空間有大小。整型占空間比較小，這樣可以存放多個鍵值。反之UUID占空間比較大。 整型比較方便，UUID比較需要先轉成ASCII在進行比較 #### **為什么非主鍵索引結構葉子節點存儲的是主鍵值？(一致性和節省存儲空間)** 1. 減少了出現行移動或者數據頁分裂時二級索引的維護工作（當數據需要更新的時候，二級索引不需要修改，只需要修改聚簇索引，一個表只能有一個聚簇索引，其他的都是二級索引，這樣只需要修改聚簇索引就可以了，不需要重新構建二級索引）； 2. 聚簇索引也稱為主鍵索引，其索引樹的葉子節點中存的是整行數據，表中行的物理順序與鍵值的邏輯（索引）順序相同。一個表只能包含一個聚集索引。因為索引（目錄）只能按照一種方法進行排序； 3. 非聚簇索引（普通索引）的葉子節點內容是主鍵的值。在 InnoDB 里，非主鍵索引也被稱為二級索引（secondary index）