基本認識

用分庫&拆表是解決數據庫容量問題的唯一途徑。

分庫&拆表也是解決性能壓力的最優選擇。

分庫 – 不同的數據表放到不同的數據庫服務器中（也可能是虛擬服務器）

拆表 – 一張數據表拆成多張數據表，可能位于同一臺服務器，也可能位于多臺服務器（含虛擬服務器）。

去關聯化原則

摘除數據表之間的關聯，是分庫的基礎工作。

摘除關聯的目的是，當數據表分布到不同服務器時，查詢請求容易分發和處理。

學會理解反范式數據結構設計，所謂反范式，第一要點是不用外鍵，不允許Join操作，不允許任何需要跨越兩個表的查詢請求。第二要點是適度冗余減少查詢請求，比如說，信息表，fromuid, touid, message字段外，還需要一個fromuname字段記錄用戶名，這樣查詢者通過touid查詢后，能夠立即得到發信人的用戶名，而無需進行另一個數據表的查詢。

去關聯化處理會帶來額外的考慮，比如說，某一個數據表內容的修改，對另一個數據表的影響。這一點需要在程序或其他途徑去考慮。

分庫方案

安全性拆分

將高安全性數據與低安全性數據分庫，這樣的好處第一是便于維護，第二是高安全性數據的數據庫參數配置可以以安全優先，而低安全性數據的參數配置以性能優先。參見運維優化相關部分。

順序寫數據與隨機讀寫數據分庫

順序數據與隨機數據區分存儲地址，保證物理i/o優化。

基于業務邏輯拆分

根據數據表的內容構成，業務邏輯拆分，便于日常維護和前端調用。

基于業務邏輯拆分，可以減少前端應用請求發送到不同數據庫服務器的頻次，從而減少鏈接開銷。

基于業務邏輯拆分，可保留部分數據關聯，前端web工程師可在限度范圍內執行關聯查詢。

基于負載壓力拆分

基于負載壓力對數據結構拆分，便于直接將負載分擔給不同的服務器。

基于負載壓力拆分，可能拆分后的數據庫包含不同業務類型的數據表，日常維護會有一定的煩惱。

分表方案

數據量過大或者訪問壓力過大的數據表需要切分

忙閑分表

單數據表字段過多，可將頻繁更新的整數數據與非頻繁更新的字符串數據切分

范例user表 ，個人簡介，地址，QQ號，聯系方式，頭像 這些字段為字符串類型，更新請求少； 最后登錄時間，在線時常，訪問次數，信件數這些字段為整數型字段，更新頻繁，可以將后面這些更新頻繁的字段獨立拆出一張數據表，表內容變少，索引結構變少，讀寫請求變快。

橫向切表

等分切表，如哈希切表或其他基于對某數字取余的切表。等分切表的優點是負載很方便的分布到不同服務器；缺點是當容量繼續增加時無法方便的擴容，需要重新進行數據的切分或轉表。而且一些關鍵主鍵不易處理。

遞增切表，比如每1kw用戶開一個新表，優點是可以適應數據的自增趨勢；缺點是往往新數據負載高，壓力分配不平均。

日期切表，適用于日志記錄式數據，優缺點等同于遞增切表。

個人傾向于遞增切表，具體根據應用場景決定。

熱點數據分表

將數據量較大的數據表中將讀寫頻繁的數據抽取出來，形成熱點數據表。通常一個龐大數據表經常被讀寫的內容往往具有一定的集中性，如果這些集中數據單獨處理，就會極大減少整體系統的負載。

熱點數據表與舊有數據關系

可以是一張冗余表，即該表數據丟失不會妨礙使用，因源數據仍存在于舊有結構中。優點是安全性高，維護方便，缺點是寫壓力不能分擔，仍需要同步寫回原系統。

可以是非冗余表，即熱點數據的內容原有結構不再保存，優點是讀寫效率全部優化；缺點是當熱點數據發生變化時，維護量較大。

具體方案選擇需要根據讀寫比例決定，在讀頻率遠高于寫頻率情況下，優先考慮冗余表方案。

熱點數據表可以用單獨的優化的硬件存儲，比如昂貴的閃存卡或大內存系統。

熱點數據表的重要指標

熱點數據的定義需要根據業務模式自行制定策略，常見策略為，按照最新的操作時間；按照內容豐富度等等。

數據規模，比如從1000萬條數據，抽取出100萬條熱點數據。

熱點命中率，比如查詢10次，多少次命中在熱點數據內。

理論上，數據規模越小，熱點命中率越高，說明效果越好。需要根據業務自行評估。

熱點數據表的動態維護

加載熱點數據方案選擇

定時從舊有數據結構中按照新的策略獲取

在從舊有數據結構讀取時動態加載到熱點數據

剔除熱點數據方案選擇

基于特定策略，定時將熱點數據中訪問頻次較少的數據剔除

如熱點數據是冗余表，則直接刪除即可，如不是冗余表，需要回寫給舊有數據結構。

通常，熱點數據往往是基于緩存或者key-value 方案冗余存儲，所以這里提到的熱點數據表，其實更多是理解思路，用到的場合可能并不多….

表結構設計

查詢冗余表設計

涉及分表操作后，一些常見的索引查詢可能需要跨表，帶來不必要的麻煩。確認查詢請求遠大于寫入請求時，應設置便于查詢項的冗余表。

實戰范例，

用戶分表，將用戶庫分成若干數據表

基于用戶名的查詢和基于uid的查詢都是高并發請求。

用戶分表基于uid分成數據表，同時基于用戶名做對應冗余表。

冗余表要點

數據一致性，簡單說，同增，同刪，同更新。

可以做全冗余，或者只做主鍵關聯的冗余，比如通過用戶名查詢uid，再基于uid查詢源表。

中間數據表

為了減少會涉及大規模影響結果集的表數據操作，比如count，sum操作。應將一些統計類數據通過中間數據表保存。

中間數據表應能通過源數據表恢復。

實戰范例：

論壇板塊的發帖量，回帖量，每日新增數據等

網站每日新增用戶數等。

后臺可以通過源數據表更新該數字。

歷史數據表

歷史數據表對應于熱點數據表，將需求較少又不能丟棄的數據存入，僅在少數情況下被訪問

總結

以上是生活随笔為你收集整理的MySQL 分库拆表方案的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。