大家好，我是【架構擺渡人】，一隻十年的程式猿。這是分庫分表系列的第一篇文章，這個系列會給大家分享很多在實際工作中有用的經驗，如果有收穫，還請分享給更多的朋友。
其實這個系列有錄過視訊給大家學習，但很多讀者反饋說看視訊太慢了。也不好沉澱為文件資料，希望能有一系列文字版本的講解，要用的時候可以快速瀏覽關鍵的知識點。那麼它就來了，我再花點時間寫成幾篇連續的文章供大家學習。
什麼是分庫分表？
一般，一個應用剛開始開發的時候，都是連線一個資料庫。因為這個時候業務並不複雜，處於起步階段。當然重構類的除外，重構類的是已經很明確的需求，業務也比較成熟。
分庫分表從字面去理解，就是將庫進行拆分，將表進行拆分。至於拆分的方式可以有多種，拆分的粒度也可以自行控制。
起步階段，一個資料庫，如下圖所示：
分庫後的效果，如下圖所示：
將一個庫進行拆分，必然有一定的理由和動機，那麼為什麼要分庫分表呢？
為什麼要分庫分表？
效能問題
當資料庫中的資料越來越多，請求量越來越高，效能會成為瓶頸。如果有個別SQL寫的不好，沒有走索引，則會出現全表掃描的情況，佔用資料庫的資源，影響其他請求。
儲存空間不夠
資料庫部署在一臺伺服器上面，磁碟的空間是有限的，隨著資料量的增多，磁碟的可用空間將會越來越少。如果不進行拆分，那麼資料往哪寫？
可用性更高
如果你只有一個庫，當這個庫出現問題的時候，所有的業務也就處於不能提供服務的狀態。如果拆了10個庫，10個庫在不同的伺服器上，即使某一個庫出現問題，也不會影響所有的業務。
業務劃分
當所有的業務表都在一個庫中，本身就會存在資源搶佔和相互影響的情況。同時也不利於多團隊的開發，大家的表都在一起，萬一誤操作了怎麼辦。這麼多表，哪些是我的，哪些是你的？
分庫分表的方式有哪些？
什麼是垂直拆分？
垂直拆分就是把一個資料庫拆分成多個資料庫的操作。假設你的資料庫中有使用者表，商品表，訂單表等。這些是屬於不同的業務場景，就算不從效能的角度考慮，也要進行拆分，這個就是根據業務進行劃分，這就是垂直拆分的一種。
進行垂直拆分之後結構更清晰了，資料庫的整體效能也上來了。以前一個庫要頂住1W的QPS,現在平攤到三個資料庫上面了，每個資料庫只需要頂住3K多就夠了，前提是你這3個資料庫必須是獨立的例項。
垂直拆分，也同時瞭解決了儲存的問題，整體的儲存空間其實也拆分開了。
什麼是水平拆分
水平拆分跟垂直拆分可以進行互補，垂直拆分主要是容量和業務劃分的拆分。水平拆分主要就是為了解決容量和效能問題的拆分。
比如你拆了訂單庫，商品庫，使用者庫。但是訂單庫還是在一個資料庫上面，他的效能和儲存還是有瓶頸的。此時就要進行水平拆分了，水平拆分就是把一個訂單庫，拆分成多個庫，一個訂單表拆分成多個表。
訂單庫從一個庫一個表拆分成多個庫多個表，如下圖所示：
總結
今天主要跟大家講了下背景，以及為什麼要做分庫分表。讓大家有個整體的概念，這樣後面學習起來就會比較容易了。
雖然我們知道要做分庫分表，但是在分的時候該怎麼分呢？垂直和水平如何搭配，才能幹活不累呢？請關注我，下篇文章為你揭祕。
原創：架構擺渡人（公眾號ID：jiagoubaiduren），歡迎分享，轉載請保留出處。
本文已收錄至學習網站 http://cxytiandi.com/ ，裡面有Spring Boot, Spring Cloud，分庫分表，微服務，面試等相關內容。