建表在日常開發中必不可少，但設計出來的表卻千差萬別，前期表單設計得不好，對後期維護和優化都會產生非常大的阻力，那麼我們需要如何優雅地建立我們的主鍵呢？下面我們慢慢道來
mysql是由b+樹構成，搞清楚下面兩個問題，就知道為什麼用b+樹了。
1.b+tree是為磁碟或者其他直接訪問輔助裝置而設計的一種平衡二叉樹?
答：資料庫系統的設計者巧妙利用了磁碟預讀原理，將乙個節點的大小設為等於乙個頁，這樣每個節點只需要一次i/o就可以完全載入。為了達到這個目的，在實際實現b+tree還需要使用如下技巧：每次新建節點時，直接申請乙個頁的空間，這樣就保證乙個節點物理上也儲存在乙個頁裡，加之計算機儲存分配都是按頁對齊的，就實現了乙個node只需一次i/o。
②b+tree的節點都是按照鍵值的大小順序存放的，葉節點之間也通過指標連線起來，為了提高取資料時的效率。
我先把結論給出來，方便喜歡直接套用的童鞋，但是對技術有追求的人來說，還是了解下原理比較有說服力。1.效能消耗
從上面的原理可以得知，mysql會按照鍵值的大小進行順序存放，如果我們設定自增id為主鍵，這個時候主鍵是按照一種緊湊的接近順序寫入的方式進行儲存資料。
如果我們用其他字段作為主鍵的話，此時mysql不得不為了將新記錄插到合適位置而移動資料，甚至目標頁面可能已經被回寫到磁碟上而從快取中清掉，此時又要從磁碟上讀回來，這增加了很多額外的開銷，同時頻繁的移動、分頁操作造成了大量的碎片。
2.資源消耗
同樣資料量的情況下，自增id主鍵的資料量是字串主鍵的1/2，對於考慮成本的公司來說無疑是一件好事，並且資料量小對備份還原資料都有大大的好處。
二.uuid或者自增id+步長
小規模分布式在資料量不大，使用成本最低的方式就直接用uuid，或者自增id+步長的方式，省時省力。
三.自建的id生成器
當資料量比較大，又是分布式架構的時候，可能我們需要考慮各種分庫分表方案了，這個時候就不能貪圖方便，必須有更好更長遠的方案來替代。自建id生成器，可以保證全域性唯一，可以參考snowflake的演算法（18位）方案，具體實施也可以根據自身業務進行調整演算法。其次需要考慮的就是服務的高可用。
Mysql選擇主鍵
對於乙個表來說主鍵選用的好壞直接關係到對於該錶的操作效能，因此主鍵選用的好壞很大程度上決定了表的相關效能。一般來說選用主鍵需要遵循以下規則 int型別在做比較運算時會獲取更好的效能 cpu比較週期縮短 int型別是順序排列的這樣在索引中邏輯上相鄰的資料就分布在磁碟相鄰的地方 大大減少io次數 主鍵長...
Mysql選擇主鍵
對於乙個表來說主鍵選用的好壞直接關係到對於該錶的操作效能，因此主鍵選用的好壞很大程度上決定了表的相關效能。一般來說選用主鍵需要遵循以下規則 int型別在做比較運算時會獲取更好的效能 cpu比較週期縮短 int型別是順序排列的這樣在索引中邏輯上相鄰的資料就分布在磁碟相鄰的地方 大大減少io次數 主鍵長...
mysql 主鍵選擇
最近研究uuid，收集的一些資料 mysql uuid函式的詳解 mysql中可以有二類用於生成唯一值性質的工具 uuid 函式和自增序列，那麼二者有何區別呢？我們就此對比下各自的特性及異同點 l 都可以實現生成唯一值的功能 l uuid是可以生成時間 空間上都獨一無二的值 自增序列只能生成基於表內...