業務快速發展，單資料庫出現效能瓶頸的時候，要將資料進行切分。將原來在一台資料庫上的資料，分散到多台資料庫中，降低單體資料庫負載
垂直切分是將多個業務模組拆分到多個資料庫中，也就是將原有單個資料庫的表根據業務模組放入多個資料庫中。
比如，訂單表和商品表在同乙個資料庫中，而現在我們要對其進行切分，使得訂單表和商品表分別落在不同的物理機中的不同資料庫中，使其完全隔離，從而達到降低資料庫負載的效果。如圖所示：
水平切分是將原有一張表根據規律劃分成多張表
水平拆分相比垂直拆分，更為複雜。它需要將乙個表中的資料，根據某種規則拆分到不同的資料庫中，例如：訂單尾號為奇數的訂單放在訂單資料庫1中，而訂單尾號為偶數的訂單放在了訂單資料庫2中。這樣原本存在於乙個資料庫中的資料，被水平的切分為了兩個資料庫。在查詢訂單資料時，我們還要根據訂單的尾號，判斷這個訂單在資料庫1中，還是在資料庫2中，然後將這條sql語句傳送到正確的證據庫分鐘，查出訂單。水平切分的架構圖如下：
水平拆分資料，要先訂單拆分的規則，找到你要按哪個維度去拆分，還是前面訂單的例子，我們按照訂單尾號的奇偶數去拆分，那麼這樣拆分會有什麼影響呢？假如我是乙個使用者，我下了兩個訂單，乙個訂單尾號為奇數，乙個訂單尾號為偶數，這時，我去個人中心，訂單列表頁去檢視我的訂單。那麼這個訂單列表頁要去怎麼查詢，要根據我的使用者id分別取出訂單1庫和訂單2庫去查詢出訂單，然後再合併成乙個列表，是不是很麻煩。所以，咱們在拆分資料時，一定要結合業務，選擇出適合當前業務場景的拆分規則。那麼按照使用者id去拆分資料就合理嗎？也不一定，比如：咱們的身份變了，不是買家了，而是賣家，我這個賣家有很多的訂單，賣家的後台系統也有訂單列表頁面，那這個訂單列表頁要怎麼樣去查？是不是也要在所有的訂單庫中查一遍，然後再聚合成乙個訂單列表呀。那這樣看，是不是按照使用者id去拆分訂單又不合理了
有幾種水平拆分的典型分片規則：
上圖是按照使用者id去求模拆分的乙個示意圖
無論是垂直切分，還是水平切分，它們解決了海量資料的儲存和訪問效能問題，但也隨之而來的帶來了很多新問題，它們的共同缺點有：
針對多資料來源的管理問題，主要有兩種思路：
客戶端模式，在每個應用模組內，配置自己需要的資料來源，直接訪問資料庫，在各模組內完成資料的整合
中間**模式，中間**統一管理所有的資料來源，資料庫層對開發人員完整透明，開發人員無需關注拆分的細節
資料庫為什麼要分庫分表
1 基本思想之什麼是分庫分表？從字面上簡單理解，就是把原本儲存於乙個庫的資料分塊儲存到多個庫上，把原本儲存於乙個表的資料分塊儲存到多個表上。2 基本思想之為什麼要分庫分表？資料庫中的資料量不一定是可控的，在未進行分庫分表的情況下，隨著時間和業務的發展，庫中的表會越來越多，表中的資料量也會越來越大，相...
資料庫為什麼要分庫分表
1 基本思想之什麼是分庫分表？從字面上簡單理解，就是把原本儲存於乙個庫的資料分塊儲存到多個庫上，把原本儲存於乙個表的資料分塊儲存到多個表上。2 基本思想之為什麼要分庫分表？資料庫中的資料量不一定是可控的，在未進行分庫分表的情況下，隨著時間和業務的發展，庫中的表會越來越多，表中的資料量也會越來越大，相...
為什麼要分庫分表
初學者在看到這個問題的時候，可能首先想到的是 mysql 一張表到底能存放多少條資料？根據 mysql 官方文件的介紹，mysql 理論上限是232 受限於32位軟體 條資料，然而實際操作中，往往還受限於下面兩條因素 myisamdatapointersize，mysql 的 myisamdatap...