MySQL數(shù)據(jù)庫架構(gòu)設(shè)計(jì)的基本功就是對于表結(jié)構(gòu)的設(shè)計(jì)。
如對于字段類型的選擇；表的存儲設(shè)計(jì)，壓縮還是非壓縮，如何選用壓縮算法；表的訪問設(shè)計(jì)，SQL還是NoSQL。
這些問題看似非常簡單并容易回答，然而絕大部分的答案卻是錯(cuò)的。
某些錯(cuò)的離譜的答案還在網(wǎng)上年復(fù)一年的流傳著，甚至還成為了所謂的MySQL軍規(guī)。
其中，一個(gè)最明顯的錯(cuò)誤就是關(guān)于MySQL的主鍵設(shè)計(jì)。
大部分人的回答如此自信：用8字節(jié)的 BIGINT 做主鍵，而不要用INT。
這樣的回答，只站在了數(shù)據(jù)庫這一層，而沒有從業(yè)務(wù)的角度思考主鍵到底什么？
主鍵就是一個(gè)自增ID么？
站在2021年的時(shí)間當(dāng)下，用自增做主鍵，架構(gòu)設(shè)計(jì)上可能連及格分都拿不到。
自增ID的問題
自增ID做主鍵，簡單易懂，幾乎所有數(shù)據(jù)庫都支持自增類型，只是實(shí)現(xiàn)上各自有所不同而已。
自增ID除了簡單，其他都是缺點(diǎn)，總體來看存在以下幾方面的問題。
首先，可靠性不高。存在自增ID回溯的問題，這個(gè)問題直到最新版本的MySQL 8.0才修復(fù)。
其次，安全性不高。對外暴露的接口可以非常容易猜測對應(yīng)的信息。
比如/User/1/這樣的接口，可以非常容易猜測用戶ID的值為多少，總用戶數(shù)量有多少，也可以非常容易地通過接口進(jìn)行數(shù)據(jù)的爬取。
另外容易被忽視的一點(diǎn)是，自增ID的性能較差，需要在數(shù)據(jù)庫服務(wù)器端生成。
而且業(yè)務(wù)還需要額外執(zhí)行一次類似last_insert_id()的函數(shù)才能知道剛才插入的自增值，這需要多一次的網(wǎng)絡(luò)交互。
在海量并發(fā)的系統(tǒng)中，多1條SQL，就多一次性能上的開銷。
最后也是最重要的一點(diǎn)是，自增ID是局部唯一，只在當(dāng)前數(shù)據(jù)庫實(shí)例中唯一，而不是全局唯一，在任意服務(wù)器間都是唯一的。
對于目前分布式系統(tǒng)來說，這簡直就是噩夢。
淘寶的主鍵設(shè)計(jì)
在淘寶的電商業(yè)務(wù)中，訂單服務(wù)是一個(gè)核心業(yè)務(wù)。
那么請問，訂單表的主鍵淘寶是如何設(shè)計(jì)的呢？是自增ID么？
打開淘寶，看一下訂單信息：
從上圖可以發(fā)現(xiàn)，訂單號不是自增ID！！！
接著，我們詳細(xì)看下上述4個(gè)訂單號：
1550672064762308113
1481195847180308113
1431156171142308113
1431146631521308113
注意到了什么沒？訂單號是20位的長度，且訂單的最后6位都是一樣的，都是308113。
此外，訂單號的前面14位部分是單調(diào)遞增的。所以，我大膽猜測，淘寶的訂單ID設(shè)計(jì)應(yīng)該是：
訂單ID = 時(shí)間 + 去重字段 + 用戶ID后6位尾號
這樣的設(shè)計(jì)能做到全局唯一，且對分布式系統(tǒng)查詢及其友好。
主鍵的設(shè)計(jì)
看到這里，姜老師想說的是自增ID只適合用于非核心業(yè)務(wù)，如告警、日志、監(jiān)控等信息。
對于核心業(yè)務(wù)表，主鍵設(shè)計(jì)至少應(yīng)該是全局唯一且是單調(diào)遞增。全局唯一保證在各系統(tǒng)之間都是唯一的，單調(diào)遞增是希望插入時(shí)不影響數(shù)據(jù)庫性能。
這里姜老師推薦最簡單的一種主鍵設(shè)計(jì)：UUID。
我知道很多同學(xué)會說：UUID啊，雖然全局唯一，但是占用36字節(jié)，數(shù)據(jù)無序，插入性能差。
在得到上述結(jié)論前，是不是應(yīng)該先回答以下這樣問題呢？
- 為什么UUID是全局唯一的？
- 為什么UUID占用36個(gè)字節(jié)？
- 為什么UUID是無序的？
好吧，接著姜老師來手把手的給你講解UUID。
MySQL數(shù)據(jù)庫的UUID實(shí)現(xiàn)是Version 1的版本實(shí)現(xiàn)，其組成如下所示：
UUID = 時(shí)間低（8字節(jié)）- 時(shí)間中高+版本（8字節(jié)）- 時(shí)鐘序列 - mac地
為了更為詳細(xì)的講解UUID的實(shí)現(xiàn)，我們以UUID值
e0ea12d4-6473-11eb-943c-00155dbaa39d舉例，其具體組成如下圖所示：
在UUID中他的時(shí)間部分占用60位，存儲的類似TIMESTAMP的時(shí)間戳，但表示的是從1582-10-15 00：00：00.00到現(xiàn)在的100ns的計(jì)數(shù)。
可以看到UUID存儲的時(shí)間精度比TIMESTAMPE更高，時(shí)間維度發(fā)生重復(fù)的概率降低到1/100ns。
時(shí)鐘序列是為了避免時(shí)鐘被回?fù)軐?dǎo)致產(chǎn)生時(shí)間重復(fù)的可能性。MAC地址用于全局唯一。這回答了為什么UUID可以是全局唯一的問題。
UUID根據(jù)字符串進(jìn)行存儲，設(shè)計(jì)時(shí)還帶有無用"-"字符串，因此總共需要36個(gè)字節(jié)。
最后，為什么UUID是隨機(jī)無序的呢？
因?yàn)?strong>UUID的設(shè)計(jì)中，將時(shí)間低位放在最前面，而這部分的數(shù)據(jù)是一直在變化的，并且是無序！！！
若將時(shí)間高低位互換，則時(shí)間就是單調(diào)遞增的了，也就變得單調(diào)遞增了。
MySQL 8.0解決了UUID存在的問題，除去了UUID字符串中無意義的"-"字符串，并且將字符串用二進(jìn)制類型保存，這樣存儲空間降低為了16字節(jié)。
更重要的是，他可以更換時(shí)間低位和時(shí)間高位的存儲方式，這樣UUID就是有序的UUID了。
可以通過MySQL8.0提供的uuid_to_bin函數(shù)實(shí)現(xiàn)上述功能，同樣的，MySQL也提供了bin_to_uuid函數(shù)進(jìn)行轉(zhuǎn)化：
所以，現(xiàn)在起可以通過函數(shù)uuid_to_bin(@uuid,true)將UUID轉(zhuǎn)化為有序UUID了。
全局唯一 + 單調(diào)遞增，這不就是我們想要的主鍵實(shí)現(xiàn)么？
BTW，8.0之前的版本沒有提供這兩個(gè)函數(shù)，有聰明的小伙伴知道怎么實(shí)現(xiàn)么？歡迎留言。
有序UUID性能測試
16字節(jié)的有序UUID，相比之前8字節(jié)的自增ID，性能和存儲空間對比究竟如何呢？
我們來做一個(gè)測試，插入1億條數(shù)據(jù)，每條數(shù)據(jù)占用500字節(jié)，含有3個(gè)二級索引，最終的結(jié)果如下所示：
從上圖可以看到插入1億條數(shù)據(jù)有序UUID是最快的，而且在實(shí)際業(yè)務(wù)使用中有序UUID在業(yè)務(wù)端就可以生成。還可以進(jìn)一步減少SQL的交互次數(shù)。
另外，雖然有序UUID的相比自增ID多了8個(gè)字節(jié)，但實(shí)際只增大了3G的存儲空間。
存儲空間的增大并沒有小伙伴想象中的那么大。
總結(jié)
在當(dāng)今的互聯(lián)網(wǎng)環(huán)境中，非常不推薦自增ID作為主鍵的數(shù)據(jù)庫設(shè)計(jì)。
更推薦類似有序UUID的全局唯一的實(shí)現(xiàn)。
另外在真實(shí)的業(yè)務(wù)系統(tǒng)中，主鍵還可以加入業(yè)務(wù)和系統(tǒng)屬性，如用戶的尾號，機(jī)房的信息等。
這樣的主鍵設(shè)計(jì)就更為考驗(yàn)架構(gòu)師的水平了。
今天所介紹的全部內(nèi)容都在拉鉤教育新推出的專欄《姜承堯的MySQL實(shí)戰(zhàn)寶典》中，歡迎大家訂閱。
