淘寶的數據庫，主鍵是如何設計的？

破產碼農

IT 圈最會講故事的網紅 · 南山彭于晏

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

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

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

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

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

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

以上全錯。

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

主鍵就是一個自增 ID 麼？

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

1

自增 ID 的問題

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

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

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

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

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

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

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

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

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

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

2

淘寶的主鍵設計

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

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

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

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

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

1550672064762308113
1481195847180308113
1431156171142308113
1431146631521308113

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

此外，訂單號的前面 14 位部分是單調遞增的。

所以，我大膽猜測，淘寶的訂單 ID 設計應該是：

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

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

3

主鍵的設計

看到這裏，姜老師想說的是自增 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 之前的版本沒有提供這兩個函數，有聰明的小夥伴知道怎麼實現麼？歡迎留言。

4

有序 UUID 性能測試

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

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

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

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

存儲空間的增大並沒有小夥伴想象中的那麼大。

5

總結

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

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

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

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

公衆號：破產碼農

視頻號：破產碼農

抖音號：破產碼農

B 站號：姜老師帶你飛

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/llxnxiwl59RSmpFsI7HDRQ