今天和大家聊聊分庫分表技術，大家面試的時候肯定都有這樣的經歷，面試官動不動就問分庫分表、高併發、虛擬機器、分散式事務等等這些高大上的技術。所以我們還是有必要要了解一下的。

分表：

分表的意思是在一個庫裡面進行表拆分，很常見的就是日誌表了，分表的規則有按天的、也有按月的。

這種分表技術是早期的技術了，現在基本沒這樣做了，在某些特殊的場景下面可能會出現。而且這樣的分表技術一般都是通過程式碼來進行的，需要自己開發，很少有第三方整合好的。

分庫：

分庫和分表就不一樣了，分表是所有資料都在一個庫裡面，分庫則不同，不同的庫存放的表都是一樣的。

這種方式有點類似Mysql的主從資料庫，主庫和從庫的資料都是一樣的。在資料量大的情況下，查詢速度還是會特別慢，因為每一個庫表的資料量是一樣的。

分庫分表：

整合上面兩種方式的特點，就出現了第三種方式：分庫分表，分庫的同時進行分表。

分庫分表的特點就是如上圖所示，每一個庫中表都存一部分的資料，這樣表不管有多大，我們都可以通過增加庫來負載這個資料量。這邊需要注意的是，資料新增和獲取都需要遵守一定的規則，常見的有雜湊、取模、範圍區間等等。我們可以通過一個第三方的框架來實現這個功能，比如mycat。

分庫分表缺點：

採用分庫分表方式有一個缺點，如果我們僅僅是查詢某一個數據，可以很快速的確定某一個庫，然後查詢返回資料。但是如果做資料統計，這個時候效率就會慢的驚人。因為統計的話，需要一個一個庫裡面去遍歷，在資料量大的情況下，還不如一個表裡面數據查詢好。這邊的解決方案是將資料彙總到一個倉庫中，在這個倉庫中進行統計，倉庫如果不是海量資料的情況下，可以用es來做，是海量資料可以升級為大資料。

高可用：

統計的問題解決了，後期要做的就是如何實現高可用，這邊的高可用指的是，儘可能保證資料庫可用。這邊我們首先要做的就是每一個庫都做一個從庫，如果主庫出現問題，從庫可以馬上接替主庫，還可以做讀寫分離，增加資料庫的負載量。

到這一步之後，我們這個體系的瓶頸就跑到mycat這邊了，如果mycat掛了，那所有的庫都無法訪問了，這顯然是無法忍受的，所以我們mycat也是需要高可用的，啟動多個mycat，通過框架進行負載均衡即可。

總結：

架構升級都是一步一步來的，在使用者量小的情況下，沒必要一下子就部署高可用版本的方案，資源利用不到本身就是一種浪費。一般前期分庫分表，統計和高可用的方案在資料量小的情況下可以不採用，後期升級的時候加上去就可以了。好了今天的內容就介紹到這邊了，謝謝大家的閱讀～

要更多幹貨、技術猛料的孩子，快點拿起手機掃碼關注我，我在這裡等你哦~