一、介紹 單庫瓶頸：如果在項目中使用的都是單MySQL伺服器，則會隨著互聯網及移動互聯網的發展，應用系統的數據量也是成指數式增長，若採用單資料庫進行存儲，存在一下性能瓶頸： IO瓶頸：熱點數據太多，資料庫緩存不足，產生大量磁碟IO,效率低下，請求數據太多，帶寬不夠，網路IO瓶頸。 CPU瓶頸：排序、 ...
一、介紹
單庫瓶頸：如果在項目中使用的都是單MySQL伺服器，則會隨著互聯網及移動互聯網的發展，應用系統的數據量也是成指數式增長，若採用單資料庫進行存儲，存在一下性能瓶頸：
- IO瓶頸：熱點數據太多，資料庫緩存不足，產生大量磁碟IO,效率低下，請求數據太多，帶寬不夠，網路IO瓶頸。
- CPU瓶頸：排序、分組、連接查詢、聚合統計等SQL會耗費大量的CPU資源，請求數太多，CPU出現瓶頸。
分庫分表：就是將數據分散存儲，是將單一資料庫/表的數據量變小來緩解單一資料庫的性能問題，從而達到提升資料庫性能的目的。
二、拆分策略
2.1 垂直分庫
特點：以表為依據，根據業務將不同表拆分到不同庫中。
-
- 每個庫的表結構都不一樣
- 每個表的數據也不一樣
- 所有庫的並集是全量數據
2.2 垂直分表
特點：以欄位為依據，根據欄位屬性將不同欄位分到不同表中 。
-
- 每個表的結構都不一樣
- 每個表的數據也不一樣，一般通過一列（主鍵/外鍵）管理
- 所有表的並集是全量數據
2.3 水平分庫
特點：以欄位為依據，按照一定策略，將一個庫的數據拆分到多個庫中
-
- 每個庫的表結構一樣。
- 每個庫的數據都不一樣
- 所有庫的並集是全量數據
2.4 水平分表
特點：以欄位為依據，按照一定策略，將一個表的數據拆分到多個表中。
-
- 每個表的結構都一樣
- 每個表的數據都不一樣
- 所有表的並集是全量數據
2.5 組合策略
在實際應用中，可以同時採用分庫和分表的策略，根據業務需求和系統負載情況來選擇合適的分庫分表策略。
三、分庫分別鍵
3.1 業務鍵
根據業務需求，選擇具有業務含義的鍵作為分庫分表的依據，例如，按照用戶ID分表
3.2 時間鍵
對於大部分應用來說，按時間進行分表是一個常見的選擇，可以更容易地管理歷史數據
3.3 哈希建
使用哈希函數將數據均勻地分散到不同的庫或表中，以防止熱點數據集中存儲
3.4 範圍鍵
按照數據範圍進行分表，適用於數據按照某一範圍規律增長的情況
侯哥語錄：我曾經是一個職業教育者，現在是一個自由開發者。我希望我的分享可以和更多人一起進步。分享一段我喜歡的話給大家："我所理解的自由不是想乾什麼就乾什麼，而是想不幹什麼就不幹什麼。當你還沒有能力說不得時候，就努力讓自己變得強大，擁有說不得權利。"
