場景問題
當系統的訪問量達到上百萬用戶時，系統的性能達到了上限，系統已經做了一輪輪優化：
（1）應用集羣
（2）程序優化
（3）數據庫優化（SQL優化、集羣）
（4）數據緩存
（5）網絡優化（加大帶寬、多個網卡）
（6）操作系統優化
但是，系統到了又一個瓶頸，在怎麼優化都沒有什麼效果了。通過性能跟蹤，發現是數據庫的數據量太大了（幾張表都達到了10億條數據了），而且隨着系統的用戶訪問數據是不停的往上增加。SQL無論怎麼優化，數據操作的時間已經達到了一個極限了。
發現數據庫服務器的CPU和IO已經都達到了100％，可見，當前機器的硬件情況已經到達了極限，接下來怎麼辦呢?有人說，把機器換成一臺更加強大的機器，磁盤做磁盤陣列。沒錯，這些做完後，緩解了性能的瓶頸，但是，隨着數據量的增加，性能瓶頸又一次出現了。機器又達到極限了。再換更強大的機器，以此類推。機器真的能無止境的變強下去嗎?
我們看到了應用可以集羣，那麼數據爲什麼不能集羣呢？瞭解後才發現，數據的集羣不是那麼回事，雖然訪問的是多臺機器了，但數據還是同一份。最終IO的瓶頸還是會出現。
能不能仿照應用集羣那樣，有一個HTTP服務器和多個應用服務器。數據也有一個總控制器和多個數據服務器？那就需要將數據進行切分成一塊塊的，分佈在不同的機器上。這樣我們可以無限制的進行數據切分，無限制的增加數據服務器。
這個時候我們又遇到新的問題：怎麼切分纔是合理的？怎麼才能找到對應的數據塊呢？下面我們介紹怎麼通過數據分庫來解決以上的問題。
數據分庫：基於性能考慮，將數據存放到不同的數據庫服務器中，一般可以按兩個緯度來拆分數據:
垂直拆分：是指按功能模塊拆分，比如CRM可以將客戶信息、訂單信息、產品信息存放在不同的數據庫中，這種方式多個數據庫之間的表結構不同。
水平拆分：而水平拆分是將同一個表的數據進行分塊保存到不同的數據庫中，比如：可以將客戶信息按照不同市分別存放在不同的數據庫中，這些數據庫中的表結構完全相同。