總結(jié)Mysql數(shù)據(jù)庫:分表、分庫

1.演化過程

單庫單表--->單庫多表 || 多庫單表--->多庫多表

2.何時分表?何時分庫?

分表:解決單張表數(shù)據(jù)量過大導(dǎo)致的查詢效率低下。但是分表無法提高數(shù)據(jù)庫并發(fā)處理能力;
分庫:提高數(shù)據(jù)庫高并發(fā)讀寫能力。

3.路由訪問策略

分表、分庫都可以采用通過一個關(guān)鍵字取模的方式,來對數(shù)據(jù)訪問進行路由
如下圖所示:

分庫路由訪問策略

4.分庫分表---利弊

任何事物都具有兩面性
分庫分表
好處:提高了數(shù)據(jù)庫并發(fā)處理能力、單張數(shù)據(jù)量過大的查詢效率。
弊端:
1 事務(wù)問題

在執(zhí)行分庫分表之后,由于數(shù)據(jù)存儲到了不同的庫上,數(shù)據(jù)庫事務(wù)管理出現(xiàn)了困難。如果依賴數(shù)據(jù)庫本身的分布式事務(wù)管理功能去執(zhí)行事務(wù),將付出高昂的性能代價;如果由應(yīng)用程序去協(xié)助控制,形成程序邏輯上的事務(wù),又會造成編程方面的負擔(dān)。

2 跨庫跨表的join問題

在執(zhí)行了分庫分表之后,難以避免會將原本邏輯關(guān)聯(lián)性很強的數(shù)據(jù)劃分到不同的表、不同的庫上,這時,表的關(guān)聯(lián)操作將受到限制,我們無法join位于不同分庫的表,也無法join分表粒度不同的表,結(jié)果原本一次查詢能夠完成的業(yè)務(wù),可能需要多次查詢才能完成。

3 額外的數(shù)據(jù)管理負擔(dān)和數(shù)據(jù)運算壓力

額外的數(shù)據(jù)管理負擔(dān),最顯而易見的就是數(shù)據(jù)的定位問題和數(shù)據(jù)的增刪改查的重復(fù)執(zhí)行問題,這些都可以通過應(yīng)用程序解決,但必然引起額外的邏輯運算。
例如: 對于一個記錄用戶成績數(shù)據(jù)表userTable,業(yè)務(wù)要求查出成績最好的100位.
在進行分表之前,只需一個order by語句就可以搞定,但是在進行分庫分表之后,將需要n個order by語句,分別查出每一個分庫分表的前100名用戶數(shù)據(jù),然后再對這些數(shù)據(jù)進行合并計算,才能得出結(jié)果。

解決方案

  1. 使用類似JTA提供的分布式事物機制

參考文章:

MySql從一竅不通到入門(五)Sharding:分表、分庫、分片和分區(qū)

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務(wù)。

友情鏈接更多精彩內(nèi)容