為什麼建議主鍵整型自增？

昨天看到一個MySQL資料庫設計原則：強烈建議表的主鍵使用整型自增主鍵。為啥呢？

要弄明白這個問題首先需要瞭解MySQL是如何維護數據的，你需要知道以下幾點：

• MySQL的InnoDB存儲引擎是在B+樹上維護表數據的
• B+樹是一種平衡樹
• 在這棵樹上，每個節點在電腦中叫做數據頁，預設16k
• 樹的葉子節點是完整的行數據，非葉子節點是主鍵
• 葉子節點中的行數據按id從小到大的順序排列

PS：MySQL索引底層數據結構詳細分析過程參考這篇深入分析MySQL索引底層原理

查詢過程

明白了MySQL維護數據的方式，下麵我們再來看一下如何在這棵樹上查詢數據。

假設我們有個T表，表結構和數據如下：

CREATE TABLE `T` (
`id` int(11) NOT NULL AUTO_INCREMENT COMMENT 'id',
`name` varchar(50) COMMENT '姓名',
 PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
insert into T(id,name) 
values(1,'張三'),(2,'李四'),(3,'王五'),(5,'趙六');

瞭解了MySQL維護數據的方式，我們可以把T表的數據存儲邏輯結構畫出來：

如上圖所示，根節點上維護了主鍵2和5，兩個葉子節點分別存兩條記錄。

當我們查詢id=2的記錄時，首先會從樹的根節點開始遍歷，通過與根節點的id值比較，定位到記錄在第一個葉子節點，然後把第一個葉子節點從磁碟載入到記憶體，在記憶體中依次讀取記錄進行比較：

• 讀取第一個記錄，發現id不等於2跳過
• 繼續取下一個記錄，判斷id等於2
• 於是就查到了id等於2的這條記錄

可以發現，查找過程是從根節點開始的，通過與非葉子節點的id比較，定位到數據所在節點，然後依次遍歷節點上的記錄逐一對比，從而找到匹配條件的記錄。

插入過程

再來看一下插入數據，如果此時插入的數據為(6,’孫七’)，按照葉子節點的行數據排序特點（按id從小到大排），那麼(6,’孫七’)這條記錄一定在(5,’趙六’)後面，如果此時數據頁P3還能存下，則直接順序寫入，如果數據頁P3存不下這條記錄，InnoDB會申請一個新的數據頁P4寫入(6,’孫七’)，這個過程叫做頁分裂。

如果此時插入的數據為(4,’孫七’)，按照葉子節點的行數據排序特點（按id從小到大排），那麼(4,’孫七’)這條記錄一定在(3,’王五’)後面(5,’趙六’)前面，如果此時數據頁P3還能存下，那麼為了給(4,’孫七’)騰位置，則需要將數據頁P3上(3,’王五’)這條記錄之後的數據全部往後移動。而如果數據頁P3存不下這條記錄，InnoDB會申請一個新的數據頁P4，並將P3上部分數據轉移到P4上，在(3,’王五’)後寫入(6,’孫七’)。

為什麼主鍵建議整型、自增？

瞭解了數據的存儲方式以及查詢過程和插入過程，我們接下來進入正題，回答為什麼主鍵建議是整型、自增這個問題。

首先為什麼是整型呢？

我們從查找過程可以看到，整個過程關鍵點就是在這棵樹上不停的比較id值是否等於、大於還是小於2，即數據的大小比較。數據比較是消耗CPU的，而不同的數據類型耗時不同，常見的整型要小於字元型。

整型的1<2比較的效率高還是字元串的“abc”和“abe”比較的效率高呢？顯然是前者，因為字元串的比較是轉換成ASCII碼一位一位的比，如果最後一位不一樣，比到最後才比較出大小，就比整型比較慢多了，存儲空間來說，整型更小。索引越節約資源越好。

那為什麼自增呢？

原因也可想而知，其實上面已經提到了，就是因為InnoDB的索引是按大小排好序的，插入的新數據如果主鍵是自增的，那麼只需要按順序往後寫入即可，性能會比較高，而如果每次插入的主鍵是跳躍式的，那麼就會涉及到上面說的頁分裂，需要挪動數據，性能就會受到影響。

引申一下，是不是一定需要自增呢？

答案是不。我們都知道當某一個業務量增長非常快，數據量非常大，資料庫性能無法滿足業務需求的時候通常會實施分庫分表，這個時候自增主鍵就不適用了，比如訂單表，分成16個表，如果都使用自增的話，肯定會造成訂單id重覆，所以此時的解決方案就是分散式id，保證趨勢遞增即可。

小結

今天我通過講解MySQL數據的存儲方式以及數據查找與插入過程，從MySQL的底層機制瞭解了MySQL主鍵為什麼建議使用整型並且自增，最後我們引申了一個分散式id的問題，此時並不強制嚴格自增，保證趨勢遞增即可。

好了，今天的文章就到這裡了，如果你對於今天的文章有疑問，請留言探討。

感謝你的觀看，也歡迎你把這篇文章分享給更多的朋友一起閱讀。