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

創(chuàng)新互聯(lián)公司堅持“要么做到，要么別承諾”的工作理念，服務領域包括：成都網(wǎng)站建設、成都網(wǎng)站制作、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣等服務，滿足客戶于互聯(lián)網(wǎng)時代的沭陽網(wǎng)站設計、移動媒體設計的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡建設合作伙伴！

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

那么我們?nèi)绾谓鉀Q主鍵唯一的問題呢?這里我們介紹幾種常見的方法，以及他們的優(yōu)缺點。

方法一

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

方法二

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

方法三

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

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

以上就是數(shù)據(jù)庫分庫分表后如何解決主鍵唯一的問題，小編相信有部分知識點可能是我們?nèi)粘９ぷ鲿姷交蛴玫降?。希望你能通過這篇文章學到更多知識。更多詳情敬請關注創(chuàng)新互聯(lián)行業(yè)資訊頻道。