資料庫分庫分表估計很多夥伴都沒有實踐過，就是因為自己公司的業務不是很多，沒有那麼多資料。假如有一天專案的人數上來了，你寫的系統支撐不住了，希望這篇文章帶給你一絲絲的思路。
前言在面試過程中你是不是會經常遇到對於資料庫分庫分表你有什麼方案啊！
在平時看部落格時你是不是也經常刷到mysql如何分庫分表。
然而你是不是點進去看了不到10秒就直接退出視窗。
那是因為寫的文章不是什麼水平切分，就是垂直切割，在乙個自身所在的公司根本使用不到。
如果你只知道分庫分表但是不知道怎麼弄的話，花個五分鐘看完你會收穫到不一樣的思路。
一、初始架構
公司的規模小，專案針對的使用者群體屬於小眾。日活就幾千、幾萬的使用者這樣的資料每天的資料庫單錶增加一般不會超過10萬。併發更不沾邊了。
這種專案規模，我們就是認真、快速開發業務邏輯，提公升使用者體驗，從而提公升專案的使用者粘度並達到收納更多使用者的準備。
這個時候我們專案一台16核32g的伺服器就完全可以了，可以將資料庫單獨放乙個伺服器，也可以都放在乙個伺服器。
這個時候專案架構圖是這個樣子的。
二、使用者開始激增解決方案
在經歷了第一階段後，由於專案的使用者體驗度極高，專案又吸引了大量的使用者。
這時我們專案日活達到了百萬級別，註冊使用者也超過了千萬。這個資料是咔咔根據之前公司專案資料推算的。
這時每天單錶資料新增達到了100萬，併發請求每秒也達到了上萬。這時單系統就扛不住了。
假設每天就固定新增100萬，每月就是3000萬 ，一年就是接近5億資料。
資料庫以這種速度執行下去，資料到2000w到3000w還能勉強撐住，但是你會發現資料庫日誌會出現越來越多的慢查詢。
雖說併發1w，但是我們可以部署個10臺機器或者20臺機器，平均每台機器承擔500到1000的請求，還是綽綽有餘的。
但是資料庫方面還是用一台伺服器支撐著每秒上萬的請求，那麼你將會遇到以下問題。
資料庫所在的伺服器磁碟io、網路頻寬、cpu負載、記憶體消耗都會非常高
單錶資料已經很大，sql效能已經已經出現下坡階段，加上資料庫伺服器負載太高導致效能下降，會直接導致sql效能更差
這個時候最明顯的感覺，就是使用者獲取乙個資料可能需要10s以上的時間才會返回。
如果前期伺服器配置不是很高的話，你就會面臨資料庫宕機的情況
那麼這個時候我們要怎麼對專案進行架構的優化呢！
根據大佬們的經驗是資料庫的連線數每秒控制在2000即可、那麼我們1w併發的情況下部署5臺機器，每台機器都部署乙個同樣結構的資料庫。
此時在5臺資料庫擁有同樣的資料庫。表名規則可以這樣設定。
這時每個project庫都有乙個相同的表，比如db_project1有tb_play_recode1、db_project2有tb_play_recode2......
這樣就實現了乙個基本的分庫分表的思路，從原來一台資料庫伺服器變成了5臺資料庫伺服器，從原來乙個庫變成了5個庫，原來的一張表變成了5張表。
這時我們就需要借助資料庫中介軟體來完成寫資料，例如mycat。
實現了這個架構後，我們再來分析一下。
按照原專案的推算，一年如有1億資料，每張表就只有2000w資料。
按照每天新增50w資料，每張表每天新增10w資料，這樣是不是就初步緩解了單錶資料量過大影響系統效能問題了。
另外每秒1w的請求，這時每台伺服器平均就2000，瞬間就把併發請求降低到了安全範圍了。
三、保證查詢效能
在上邊的資料庫架構會遇到乙個問題，就是單錶資料量還是很大，按照每年1億的資料，單錶就會有2000w資料，還是太大了。
通過這個步驟就可以讓每個表的資料都非常少，按照100張表，1億資料，落到每個表的資料就只有100w。
這時的系統架構是這個樣子的。
四、配置讀寫分離來按需擴容
以上的架構整體效果已經很不錯了，假設上邊分了100張表還是不滿足需求，可以通過使用者增量計算來配置合理的表。同時還可以保證單錶內的sql執行效率。
這時還會遇到乙個問題，假如每台伺服器承載每秒2000的請求，其中就400是寫入，1600是查詢。
也就是說，增刪改查中增刪改的sql才佔到了20%的比例，80%的請求都是查詢。
安裝之前的推理，現在所有資料進行翻倍計算，每台伺服器併發達到了4000請求了。
那麼其中800請求是寫入，3200請求是查詢，如果說安裝目前的情況來擴容，就只需要增加一台資料庫伺服器即可。但是就會涉及到表的遷移，因為需要遷移一部分表到新的資料庫上，那是很麻煩的事情了。
其實沒有這個必要的，可以使用讀寫分離來解決這個問題，也就是主從複製。
寫的時候走主庫，讀資料時走從庫，這樣就可以讓乙個表的讀寫請求分開落到不同的資料庫上去執行。
這樣的設計後，我們在推算一下，假如寫入主庫的請求是400/s ,查詢從庫的請求是就是1800/s，只需要在主庫下配置倆臺從庫即可。
這時的架構是如下的。
實際的生產環境，讀請求的增長速度遠遠高於寫的請求，所以讀寫分離之後，大部分就是擴容從庫支撐更高的讀請求就可以了。
而且另外乙個點，對同乙個表，如果既寫資料，還讀資料，可能會牽扯到鎖衝突問題，無論讀還是寫效能都會有影響。
所以一旦讀寫分離之後，對主庫的表就僅僅是寫入，沒任何查詢會影響主庫。對從庫就僅僅是查詢了。
五、併發資料庫結構總結
關於併發場景下，資料庫層面的架構是需要進行精心的設計的。
並且在配置主複製時，也會有很多的問題來等著去解決。
分庫分表的落地需要借助mycat或者其他資料庫中介軟體來實現。
例如：自增id問題，主從複製資料不一致問題，在主從複製這塊很多問題，作為程式設計師的我們就是需要不停的打boos獲得最終的勝利。
堅持學習、堅持寫博、堅持分享是咔咔從業以來一直所秉持的信念。希望在偌大網際網路中咔咔的文章能帶給你一絲絲幫助。
資料庫分庫分表
1 基本思想之什麼是分庫分表？從字面上簡單理解，就是把原本儲存於乙個庫的資料分塊儲存到多個庫上，把原本儲存於乙個表的資料分塊儲存到多個表上。2 基本思想之為什麼要分庫分表？資料庫中的資料量不一定是可控的，在未進行分庫分表的情況下，隨著時間和業務的發展，庫中的表會越來越多，表中的資料量也會越來越大，相...
資料庫分庫 分表
分庫的優點是 實現簡單，庫與庫之間界限分明，便於維護，缺點是不利於頻繁跨庫操作，單錶資料量大的問題解決不了。分表的優點是 能解決分庫的不足點，但是缺點卻恰恰是分庫的優點，分表實現起來比較複雜，特別是分表規則的劃分，程式的編寫，以及後期的 資料庫拆分移植維護。實際應用中，一般網際網路企業的路線都是先分...
資料庫分庫分表
簡單了解資料庫分庫分表，以及資料庫的分片 什麼是分庫分表 原本儲存於乙個庫的資料分塊儲存到多個庫上，把原本儲存於乙個表的資料分塊儲存在到多個表上 為什麼分庫分表 當一張表的資料達到幾千萬時，你查詢一次所花的時間會變多，如果有聯合查詢的花，我想啃根會死在那。分表的目的就在於此，減少資料庫的負擔，縮短查...