關係型資料庫本身比較容易成為系統瓶頸，單機儲存容量、連線數、處理能力都有限。當單錶的資料量達到1000w或100g以後，由於查詢維度較多，即使新增從庫、優化索引，做很多操作時效能仍下降嚴重。此時就要考慮對其進行切分了，切分的目的就在於減少資料庫的負擔，縮短查詢時間。
資料庫分布式核心內容無非就是資料切分（sharding）以及切分後對資料的定位、整合。資料切分就是將資料分散儲存到多個資料庫中，使得單一資料庫中的資料量變小，通過擴充主機的數量緩解單一資料庫的效能問題，從而達到提公升資料庫操作效能的目的。
資料切分根據其切分型別，可以分為兩種方式：垂直（縱向）切分和水平（橫向）切分。
垂直切分常見有垂直分庫和垂直分表兩種。
就是根據業務耦合性，將關聯度低的不同表儲存在不同的資料庫。做法與大系統拆分為多個小系統類似，按業務
分類進行獨立劃分。與"微服務治理"的做法相似，每個微服務使用單獨的乙個資料庫。如圖：
將不同模組的資料表分庫儲存。模組間不相互關聯查詢
如果有，就需要程式設計客棧通過資料冗餘或者應層二次加工來解決。這種業務方法和資料結構最清晰。但若不能杜絕跨庫關聯查詢，宣告此路不同
是基於資料庫中的"列"進行，某個表字段較多，可以新建一張擴充套件表，將不經常用或字段長度較大的字段拆分出去到擴充套件表中。在字段很多的情況下（例如乙個大表有100多個字段），通過"大表拆小表"，更便於開發與維護，也能避免跨頁問題，mysql底層是通過資料頁儲存的，一條記錄占用空間過大會導致跨頁，造成額外的效能開銷。另外資料庫以行為單位將資料載入到記憶體中，這樣表中字段長度較短且訪問頻率較高，記憶體能載入更多的資料，命中率更高，減少了磁碟io，從而提公升了資料庫效能。
垂直切分的優點：
缺點：當乙個應用難以再細粒度的垂直切分，或切分後資料量行數巨大，存在單庫讀寫、儲存效能瓶頸，這時候就需要進行水平切分了。
水平切分分為庫內分表和分庫分表，是根據表內資料內在的邏輯關係，將同乙個表按不同的條件分散到多個資料庫或多個表中，每個表中只包含一部分資料，從而使得單個表的資料量變小，達到分布式的效果。如圖所示：
相對縱向切分這一將表分類的做法，此法是按表內每個欄位的某個規則來將資料分散儲存於不同的資料庫(或不同的表)，也就是按照數行來進行切分資料。
庫內分表只解決了單一表資料量過大的問題，但沒有將表分布到不同機器的庫上，因此對於減輕mysql資料庫的壓力來說，幫助不是很大，大家還是競爭同乙個物理機的cpu、記憶體、網路io，最好通過分庫分表來解決。
水平切分的優點：
缺點：
水平切分後同一張表會出現在多個資料庫/表中，每個庫/表的內容不同。幾種典型的資料分片規則為：
按照時間區間或id區間來切分。例如：按日期將不同月甚至是日的資料分散到不同的庫中；將userid為1~9999的記錄分到第乙個庫，10000~20000的分到第二個庫，以此類推。某種意義上，某些系統中使用的"冷熱資料分離"，將一些使用較少的歷史資料遷移程式設計客棧到其他庫中，業務功能上只提供熱點資料的查詢，也是類似的實踐。
這樣的優點在於：
缺點：一般採用hash取模mod的切分方式，例如：將 customer 表根據 cusno 字段切分到4個庫中，餘數為0的放到第乙個庫，餘數為1的放到第二個庫，以此類推。這樣同乙個使用者的資料會分散到同乙個庫中，如果查詢條件帶有cusno欄位，則可明確定位到相應庫去查詢。
優點：
缺點：
怎麼進行分庫分表以及資料遷移
已經明白為啥要分庫分表了，你也知道常用的分庫分表中介軟體了，你也設計好你們如何分庫分表的方案了 水平拆分 垂直拆分 分表 那問題來了，你接下來該怎麼把你那個單庫單錶的系統給遷移到分庫分表上去？友情提示 3個庫，每個庫里分了4個表，每個表要放50萬的資料量 假設你已經選擇了乙個分庫分表的資料庫中介軟體...
mysql分表分庫實現 MySql分表分庫思路
一.資料庫瓶頸 1.1io瓶頸 第一種 磁碟讀io瓶頸，熱點資料太多，資料庫快取放不下，每次查詢時會產生大量的io 分庫和垂直分表 第二種 網路io瓶頸，請求的資料太多，網路頻寬不夠 分庫 1.2cpu瓶頸 第一種 sql問題，如sql中包含join，group by，order by，非索引字段條...
MySQL範圍分表分庫 mysql 分表分庫策略
唯一id的生成 下面列舉幾種常見的唯一id生成方案，需要滿足兩大核心需求 1.全域性唯一 2趨勢有序 1.用資料庫的auto increment 自增id 來生成，每次通過寫入資料庫一條記錄，利用資料庫id自增的特性獲取唯一，有序的id。優點 使用資料庫原有的功能，相對簡單 能夠保證唯一 能夠保證遞...