最近在對一些大表進行優化，發現主鍵和索引設計都有爭議，就此從原理上分析主鍵設計該如何選取。

Mysql的數據結構

Mysql是由B+樹構成，搞清楚下面兩個問題，就知道為什么用B+樹了。

1.B+Tree是為磁盤或者其他直接存取輔助設備而設計的一種平衡二叉樹?

答：數據庫系統的設計者巧妙利用了磁盤預讀原理，將一個節點的大小設為等于一個頁，這樣每個節點只需要一次I/O就可以完全載入。為了達到這個目的，在實際實現B+Tree還需要使用如下技巧：每次新建節點時，直接申請一個頁的空間，這樣就保證一個節點物理上也存儲在一個頁里，加之計算機存儲分配都是按頁對齊的，就實現了一個node只需一次I/O。

②B+Tree的節點都是按照鍵值的大小順序存放的，葉節點之間也通過指針連接起來，為了提高取數據時的效率。

主鍵的選取

我先把結論給出來，方便喜歡直接套用的童鞋，但是對技術有追求的人來說，還是了解下原理比較有說服力。

非分布式架構直接套用自增id做主鍵

小規模分布式架構用uuid或者自增id+步長做主鍵

大規模分布式架構用自建的id生成器做主鍵，參考twitter的snowflake算法

一.自增id

1.性能消耗

從上面的原理可以得知，Mysql會按照鍵值的大小進行順序存放，如果我們設置自增id為主鍵，這個時候主鍵是按照一種緊湊的接近順序寫入的方式進行存儲數據。

如果我們用其他字段作為主鍵的話，此時Mysql不得不為了將新記錄插到合適位置而移動數據，甚至目標頁面可能已經被回寫到磁盤上而從緩存中清掉，此時又要從磁盤上讀回來，這增加了很多額外的開銷，同時頻繁的移動、分頁操作造成了大量的碎片。

2.資源消耗

根據mysql官方的文檔，非聚集(二級)索引都包含主鍵索引的列，所以如果主鍵太大，非聚集索引

會占用更多的磁盤空間。

二.uuid或者自增id+步長

小規模分布式在數據量不大，使用成本最低的方式就直接用uuid，或者自增id+步長的方式，省時省力。

三.自建的id生成器

當數據量比較大，又是分布式架構的時候，可能我們需要考慮各種分庫分表方案了，這個時候就不能貪圖方便，必須有更好更長遠的方案來替代。自建id生成器，可以保證全局唯一，可以參考snowflake的算法方案，具體實施也可以根據自身業務進行調整算法。唯一麻煩的就是id生成器的高可用問題，需要多加注意。

總結

以上是生活随笔為你收集整理的mysql 主键 最佳实践_设计套路：Mysql主键的选取的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。