MySQL數據庫架構設計的基本功就是對于表結構的設計。

如對于字段類型的選擇；表的存儲設計，壓縮還是非壓縮，如何選用壓縮算法；表的訪問設計，SQL還是NoSQL。

這些問題看似非常簡單并容易回答，然而絕大部分的答案卻是錯的。

某些錯的離譜的答案還在網上年復一年的流傳著，甚至還成為了所謂的MySQL軍規。

其中，一個最明顯的錯誤就是關于MySQL的主鍵設計。

大部分人的回答如此自信：用8字節的 BIGINT 做主鍵，而不要用INT。

這樣的回答，只站在了數據庫這一層，而沒有從業務的角度思考主鍵到底什么？

主鍵就是一個自增ID么？

站在2021年的時間當下，用自增做主鍵，架構設計上可能連及格分都拿不到。

自增ID的問題

自增ID做主鍵，簡單易懂，幾乎所有數據庫都支持自增類型，只是實現上各自有所不同而已。

自增ID除了簡單，其他都是缺點，總體來看存在以下幾方面的問題。

首先，可靠性不高。存在自增ID回溯的問題，這個問題直到最新版本的MySQL 8.0才修復。

其次，安全性不高。對外暴露的接口可以非常容易猜測對應的信息。

比如/User/1/這樣的接口，可以非常容易猜測用戶ID的值為多少，總用戶數量有多少，也可以非常容易地通過接口進行數據的爬取。

另外容易被忽視的一點是，自增ID的性能較差，需要在數據庫服務器端生成。

而且業務還需要額外執行一次類似last_insert_id()的函數才能知道剛才插入的自增值，這需要多一次的網絡交互。

在海量并發的系統中，多1條SQL，就多一次性能上的開銷。

最后也是最重要的一點是，自增ID是局部唯一，只在當前數據庫實例中唯一，而不是全局唯一，在任意服務器間都是唯一的。

對于目前分布式系統來說，這簡直就是噩夢。

淘寶的主鍵設計

在淘寶的電商業務中，訂單服務是一個核心業務。

那么請問，訂單表的主鍵淘寶是如何設計的呢？是自增ID么？

打開淘寶，看一下訂單信息：

從上圖可以發現，訂單號不是自增ID！！！

接著，我們詳細看下上述4個訂單號：

1550672064762308113

1481195847180308113

1431156171142308113

1431146631521308113

注意到了什么沒？訂單號是20位的長度，且訂單的最后6位都是一樣的，都是308113。

此外，訂單號的前面14位部分是單調遞增的。所以，我大膽猜測，淘寶的訂單ID設計應該是：

訂單ID = 時間 + 去重字段 + 用戶ID后6位尾號

這樣的設計能做到全局唯一，且對分布式系統查詢及其友好。

主鍵的設計

看到這里，姜老師想說的是自增ID只適合用于非核心業務，如告警、日志、監控等信息。

對于核心業務表，主鍵設計至少應該是全局唯一且是單調遞增。全局唯一保證在各系統之間都是唯一的，單調遞增是希望插入時不影響數據庫性能。

這里姜老師推薦最簡單的一種主鍵設計：UUID。

我知道很多同學會說：UUID啊，雖然全局唯一，但是占用36字節，數據無序，插入性能差。

在得到上述結論前，是不是應該先回答以下這樣問題呢？

• 為什么UUID是全局唯一的？
• 為什么UUID占用36個字節？
• 為什么UUID是無序的？

好吧，接著姜老師來手把手的給你講解UUID。

MySQL數據庫的UUID實現是Version 1的版本實現，其組成如下所示：

UUID = 時間低（8字節）- 時間中高+版本（8字節）- 時鐘序列 - mac地

為了更為詳細的講解UUID的實現，我們以UUID值
e0ea12d4-6473-11eb-943c-00155dbaa39d舉例，其具體組成如下圖所示：

在UUID中他的時間部分占用60位，存儲的類似TIMESTAMP的時間戳，但表示的是從1582-10-15 00：00：00.00到現在的100ns的計數。

可以看到UUID存儲的時間精度比TIMESTAMPE更高，時間維度發生重復的概率降低到1/100ns。

時鐘序列是為了避免時鐘被回撥導致產生時間重復的可能性。MAC地址用于全局唯一。這回答了為什么UUID可以是全局唯一的問題。

UUID根據字符串進行存儲，設計時還帶有無用"-"字符串，因此總共需要36個字節。

最后，為什么UUID是隨機無序的呢？

因為UUID的設計中，將時間低位放在最前面，而這部分的數據是一直在變化的，并且是無序！！！

若將時間高低位互換，則時間就是單調遞增的了，也就變得單調遞增了。

MySQL 8.0解決了UUID存在的問題，除去了UUID字符串中無意義的"-"字符串，并且將字符串用二進制類型保存，這樣存儲空間降低為了16字節。

更重要的是，他可以更換時間低位和時間高位的存儲方式，這樣UUID就是有序的UUID了。

可以通過MySQL8.0提供的uuid_to_bin函數實現上述功能，同樣的，MySQL也提供了bin_to_uuid函數進行轉化：

所以，現在起可以通過函數uuid_to_bin(@uuid,true)將UUID轉化為有序UUID了。

全局唯一 + 單調遞增，這不就是我們想要的主鍵實現么？

BTW，8.0之前的版本沒有提供這兩個函數，有聰明的小伙伴知道怎么實現么？歡迎留言。

有序UUID性能測試

16字節的有序UUID，相比之前8字節的自增ID，性能和存儲空間對比究竟如何呢？

我們來做一個測試，插入1億條數據，每條數據占用500字節，含有3個二級索引，最終的結果如下所示：

從上圖可以看到插入1億條數據有序UUID是最快的，而且在實際業務使用中有序UUID在業務端就可以生成。還可以進一步減少SQL的交互次數。

另外，雖然有序UUID的相比自增ID多了8個字節，但實際只增大了3G的存儲空間。

存儲空間的增大并沒有小伙伴想象中的那么大。

總結

在當今的互聯網環境中，非常不推薦自增ID作為主鍵的數據庫設計。

更推薦類似有序UUID的全局唯一的實現。

另外在真實的業務系統中，主鍵還可以加入業務和系統屬性，如用戶的尾號，機房的信息等。

這樣的主鍵設計就更為考驗架構師的水平了。

今天所介紹的全部內容都在拉鉤教育新推出的專欄《姜承堯的MySQL實戰寶典》中，歡迎大家訂閱。