在此之前我們介紹了數據庫的分庫分表問題，分庫分表可以給我們帶來非常好的擴展性與性能上的提升，但也隨之帶來一些問題，例如數據的主鍵ID分配問題。我們以Mysql為例，通常我們使用的是數據庫的自增主鍵，我們在分表的時候也盡量保證業務上不需要跨表查詢數據，但是難免會遇到這樣的場景，這個時候我們就會面臨這樣一個問題，如果兩張表上面的主鍵ID重復，那么業務就會出錯，帶來不可估量的后果。

[[311996]]

那么我們如何解決主鍵唯一的問題呢?這里我們介紹幾種常見的方法，以及他們的優缺點。

方法一

首先我們可以利用隨機方法生成主鍵，通常，只要隨機算法合理，適當地加點鹽，生成的64位的主鍵ID，重復的概率極低(幾乎可以不用考慮碰撞)，這種方法的優點是實現非常簡單，但是存在什么問題呢?首先是ID的長度會非常的長，我們都知道，在數據庫中，主鍵ID過長會降低索引的性能。其次，隨機生成主鍵ID是無序的，這就意味著插入新的數據的時候，都需要插入索引，我們都知道Mysql的索引是B+樹，B+樹如果不停地插入無序的數據，性能會大大降低，造成的結果就是插入性能降低。聰明的同學可能已經想到了，我們也可以生成有序的隨機數，例如使用Twitter公司的SnowFlake，可以一定程度上避免B+樹插入帶來的影響。

方法二

第二種方法，我們還是可以利用數據庫的主鍵遞增特性。在Mysql數據庫中，是可以設置主鍵遞增的步長，也就是我們不必在1,2,3這樣遞增，假如我們設置步長為10，開始為10，那就是10,20,30了。假如我們分了10張表，那么我們可以讓每個表的起始分別是0到9，然后步長設置為10，這樣子就可以保證十張表里面的數據不會重復了。這種方法的優點同樣非常簡單，只需要簡單的配置而已，那么它存在什么問題呢?首先是擴展非常的不方便，如果我們想要把分表從10改成20呢?會給我們帶來一定的麻煩。

方法三

第三種方法，我們可以維護一個ID分配器，我們可以使用Redis等相關組件，將提前分配好的ID放在Redis的隊列當中，每次業務要插入的時候，先從預分配的隊列中取一個元素出來，然后再插入數據庫當中。當然這種做法需要一定的開發量，可以相對保證主鍵id的順序，擴展也相對的簡單。

總結

那么哪一種方法好呢?在計算機程序設計中，沒有絕對的好也沒有絕對地差，只要能夠貼近業務，保證系統平穩運行，又不需要較大的開發與維護成本，那就是好方法，需要根據自己的業務與現在的開發運維經驗進行選擇。歡迎大家關注我，共同學習，共同進步。大家的支持是我繼續嘮嗑的動力。