表太多分成資料庫有什麼影響

在此之前我們介紹了資料庫的分庫分表問題，分庫分表可以給我們帶來非常好的擴充套件性與效能上的提升，但也隨之帶來一些問題，例如資料的主鍵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的順序，擴充套件也相對的簡單。

總結

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