數據庫分庫分表

1. 對數據庫進行分庫分表的緣由
   超大容量：
   數據表是超大表，數據庫處理能力達到極限；
   數據庫包含多個超大表。
   性能問題：
   單一服務器性能有限
   升級擴展：
   單一主庫沒法靈活地進行升級和擴展，沒法知足業務快速發展的需求
   全部業務數據都放在同一個庫中，存在單點故障風險。

2. 數據庫拆分
   將表按照業務拆分到不一樣的數據庫服務器上，同時針對大表進行分表處理，從而解決單一數據庫和數據表過大及IO服務鏈接數和IO讀寫上的瓶頸。
   常見的拆分方法有：垂直拆分、水平拆分、垂直水平拆分

3. 垂直拆分
   垂直分庫：根據業務耦合性，將關聯度低的不一樣表存儲在不一樣的數據庫。作法與大系統拆分爲多個小系統相似，按業務分類進行獨立劃分。與"微服務治理"的作法類似，每一個微服務使用單獨的一個數據庫。
   垂直分表：基於數據庫中的"列"進行，某個表字段較多，能夠新建一張擴展表，將不常常用或字段長度較大的字段拆分出去到擴展表中。在字段不少的狀況下（例如一個大表有100多個字段），經過"大表拆小表"，更便於開發與維護，也能避免跨頁問題，MySQL底層是經過數據頁存儲的，一條記錄佔用空間過大會致使跨頁，形成額外的性能開銷。另外數據庫以行爲單位將數據加載到內存中，這樣表中字段長度較短且訪問頻率較高，內存能加載更多的數據，命中率更高，減小了磁盤IO，從而提高了數據庫性能。
   優勢：(1)解決業務系統層面的耦合。(2)業務清晰與微服務的治理相似，也能對不一樣業務的數據進行分級管理、維護、監控、擴展等。(3)高併發場景下，垂直切分必定程度的提高IO、數據庫鏈接數、單機硬件資源的瓶頸。
   缺點：(1)部分表沒法join，只能經過接口聚合方式解決，提高了開發的複雜度。(2)分佈式事務處理複雜。(3)依然存在單表數據量過大的問題（須要水平切分）。

4. 水平拆分
   水平切分分爲庫內分表和分庫分表，是根據表內數據內在的邏輯關係，將同一個表按不一樣的條件分散到多個數據庫或多個表中，每一個表中只包含一部分數據，從而使得單個表的數據量變小，達到分佈式的效果。
   優勢：（1）不存在單庫數據量過大、高併發的性能瓶頸，提高系統穩定性和負載能力.（2）應用端改造較小，不須要拆分業務模塊。
   缺點：（1）跨分片的事務一致性難以保證.（2）跨庫的join關聯查詢性能較差.（3）數據屢次擴展難度和維護量極大。
   水平切分後同一張表會出如今多個數據庫/表中，每一個庫/表的內容不一樣。幾種典型的數據分片規則爲：
   1）根據數值範圍
   按照時間區間或ID區間來切分。例如：按日期將不一樣月甚至是日的數據分散到不一樣的庫中；將userId爲1~9999的記錄分到第一個庫，10000~20000的分到第二個庫，以此類推。某種意義上，某些系統中使用的"冷熱數據分離"，將一些使用較少的歷史數據遷移到其餘庫中，業務功能上只提供熱點數據的查詢，也是相似的實踐。
   這樣的優勢在於：（1）單表大小可控。（2）自然便於水平擴展，後期若是想對整個分片集羣擴容時，只須要添加節點便可，無需對其餘分片的數據進行遷移。（3）使用分片字段進行範圍查找時，連續分片可快速定位分片進行快速查詢，有效避免跨分片查詢的問題。
   缺點：熱點數據成爲性能瓶頸。連續分片可能存在數據熱點，例如按時間字段分片，有些分片存儲最近時間段內的數據，可能會被頻繁的讀寫，而有些分片存儲的歷史數據，則不多被查詢。
   2）根據數值取模
   通常採用hash取模mod的切分方式，例如：將 Customer 表根據 cusno 字段切分到4個庫中，餘數爲0的放到第一個庫，餘數爲1的放到第二個庫，以此類推。這樣同一個用戶的數據會分散到同一個庫中，若是查詢條件帶有cusno字段，則可明肯定位到相應庫去查詢。
   優勢：數據分片相對比較均勻，不容易出現熱點和併發訪問的瓶頸
   缺點：（1）後期分片集羣擴容時，須要遷移舊的數據（使用一致性hash算法能較好的避免這個問題）（2）容易面臨跨分片查詢的複雜問題。好比上例中，若是頻繁用到的查詢條件中不帶cusno時，將會致使沒法定位數據庫，從而須要同時向4個庫發起查詢，再在內存中合併數據，取最小集返回給應用，分庫反而成爲拖累。

5. 分庫分錶帶來的問題

6. 進行分表
   通過計算，將數據分到6個表中，保證在5~6年內不須要繼續進行分表。
   分表後使用靜態常量定義查詢、插入等SQL語句，表名使用replace()方法進行替換
   設計開關，將開關狀態存入redis中，經過改變狀態控制讀取舊錶或者新表