數據表設計之主鍵自增、UUID或聯合主鍵

最近在作數據庫設計的時候(以MySQL爲主)，遇到很多困惑，由於以前作數據庫表設計，基本上主鍵都是使用自增的形式，最近由於這種作法，被領導指出存在一些不足，因而我想搞明白哪裏不足。

1、MySQL爲何建議使用自增？

經過網上查閱資料，得出一個這樣的結論:
表的主鍵通常都要使用自增 id，不建議使用業務id ，是由於使用自增id能夠避免頁分裂。

按照我過去的實踐:
選擇使用自增能夠避免不少麻煩，主要體現是數據的惟一性(從1到xxx，確定不會重複的)。

1.什麼是頁分裂？

這塊我沒看太明白，我主要參考以下連接:
一看就懂的：MySQL數據頁以及頁分裂機制

爲何?mysql不推薦使用uuid或者雪花id做爲主鍵?

2、UUID做爲主鍵的優劣勢是什麼？以及它的應用場景是什麼？

1.UUID和自增int型做爲主鍵的比較,有哪些優點和劣勢？

(1)優點

• UUID值在不一樣的表、數據庫、甚至是服務器中都是全局惟一的，因此你能夠合併來自不一樣數據庫，甚至是不一樣服務器上不一樣數據庫上的數據行；
• UUID值不會在URL中暴露你的數據信息。例如，一個客戶能夠經過 id10來訪問他的帳號地址 http://www.example.com/c/10/ ，他能夠很輕鬆地猜到會有 id 11, 12等等的客戶，這可能被拖庫，或被別人猜到你的用戶量；
• UUID值生成的時候不須要查一遍數據庫，而且它還簡化了應用層的邏輯。例如，當你要給父表和子表插入數據時，通常你要先把數據插到父表裏，而後才能插到子表裏。可是若是你用UUID的話，你能夠直接生成父表的主鍵，而後在一個事務裏同時把數據插到父表和子表裏。

專業名詞解釋

拖庫:指黑客經過各類社工手段、技術手段將數據庫中敏感信息非法獲取，通常這些敏感信息包括用戶的帳號信息如用戶名、密碼；身份信息如真實姓名、證件號碼；通信信息如電子郵箱、電話、住址等。

(2)劣勢

• 存儲UUID值（16字節）須要的存儲空間比INT型（4字節）甚至是 BIGINT型（8字節）都要大;
• 調試起來會更難一些，你能夠想象一下平時你只須要 WHERE id = 10 如今你要寫 WHERE id = ‘df3b7cb7-6a95-11e7-8846-b05adad3f0ae’;
• UUID 值一般會由於它的大小和未被排序的問題致使性能問題。

參考連接:
MySQL主鍵應該用UUID仍是INT類型

一分鐘讓你瞭解拖庫、洗庫和撞庫

2.哪些應用場景應該使用UUID做爲主鍵？

簡要歸納UUID的適用場景:主要適合用在大型項目微服務架構中，保證全局ID惟一性(大型項目微服務架構集成各式各樣的子系統，避免ID衝突)。

起初我在數據表設計的時候就與項目經理爭論過，挺相似這個連接的對話:UUID與數字ID的區別與適用場景

3、什麼是聯合主鍵？聯合主鍵的適用場景又是什麼？

1.什麼是聯合主鍵

指用2個或者是2個以上的字段組成的主鍵，用這個主鍵包含的字段做爲主鍵，這個組合在數據表中是惟一，且附加上了主鍵索引。

2.聯合主鍵的適用場景是什麼？

我能想到一個用戶信息，針對某個一個區域若是用用戶ID或用戶ID+用戶姓名做爲主鍵，難以保持數據的惟一性，由於這一個地區不只僅是有一個小馬哥，可能有七八我的，如此，前面提到的用戶ID或用戶ID+用戶姓名顯然是行不通的，這時能夠把身份證加入主鍵，變成了用戶ID+用戶姓名+身份證(造成了一個聯合主鍵)，這樣一來該用戶數據的惟一性獲得了驗證。固然了，聯合主鍵的場景不只僅是這個，關鍵看業務場景。

4、數據表設計心得分享

從外包公司->創業公司->教育公司->如今所在公司，回過頭來看過去個人數據表設計方面，存在的一個最大不足，即着重考慮技術實現難易層面，而輕視業務場景適用性、擴展性、穩定性等。