數據庫分庫分表后如何解決主鍵唯一的問題

本篇文章給大家分享的是有關數據庫分庫分表后如何解決主鍵唯一的問題，小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

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

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

方法一

首先我們可以利用隨機方法生成主鍵，通常，只要隨機算法合理，適當地加點鹽，生成的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的順序，擴展也相對的簡單。

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

以上就是數據庫分庫分表后如何解決主鍵唯一的問題，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。