本文來源：

cnblogs.com/littlecharacter/p/9342129.html

一、數(shù)據(jù)庫瓶頸

1、IO瓶頸

2、CPU瓶頸

二、分庫分表

1、水平分庫

• 每個庫的結(jié)構(gòu)都一樣；
• 每個庫的數(shù)據(jù)都不一樣，沒有交集；
• 所有庫的并集是全量數(shù)據(jù)；

2、水平分表

• 每個表的結(jié)構(gòu)都一樣；
• 每個表的數(shù)據(jù)都不一樣，沒有交集；
• 所有表的并集是全量數(shù)據(jù)；

3、垂直分庫

• 每個庫的結(jié)構(gòu)都不一樣；
• 每個庫的數(shù)據(jù)也不一樣，沒有交集；
• 所有庫的并集是全量數(shù)據(jù)；

4、垂直分表

• 每個表的結(jié)構(gòu)都不一樣；
• 每個表的數(shù)據(jù)也不一樣，一般來說，每個表的字段至少有一列交集，一般是主鍵，用于關(guān)聯(lián)數(shù)據(jù)；
• 所有表的并集是全量數(shù)據(jù)；

三、分庫分表工具

• sharding-sphere：jar，前身是sharding-jdbc；
• TDDL：jar，Taobao Distribute Data Layer；
• Mycat：中間件。

注：工具的利弊，請自行調(diào)研，官網(wǎng)和社區(qū)優(yōu)先。

四、分庫分表步驟

1、非partition key的查詢問題

注：寫入時，基因法生成user_id，如圖。關(guān)于xbit基因，例如要分8張表，23=8，故x取3，即3bit基因。根據(jù)user_id查詢時可直接取模路由到對應(yīng)的分庫或分表。

根據(jù)user_name查詢時，先通過user_name_code生成函數(shù)生成user_name_code再對其取模路由到對應(yīng)的分庫或分表。id生成常用snowflake算法。

注：按照order_id或buyer_id查詢時路由到db_o_buyer庫中，按照seller_id查詢時路由到db_o_seller庫中。感覺有點(diǎn)本末倒置！有其他好的辦法嗎？改變技術(shù)棧呢？

2、非partition key跨庫跨表分頁查詢問題

注：用NoSQL法解決（ES等）。

3、擴(kuò)容問題

注：擴(kuò)容是成倍的。

• 第一步：（同步雙寫）修改應(yīng)用配置和代碼，加上雙寫，部署；
• 第二步：（同步雙寫）將老庫中的老數(shù)據(jù)復(fù)制到新庫中；
• 第三步：（同步雙寫）以老庫為準(zhǔn)校對新庫中的老數(shù)據(jù)；
• 第四步：（同步雙寫）修改應(yīng)用配置和代碼，去掉雙寫，部署；

注：雙寫是通用方案。

六、分庫分表總結(jié)

• 分庫分表，首先得知道瓶頸在哪里，然后才能合理地拆分（分庫還是分表？水平還是垂直？分幾個？）。且不可為了分庫分表而拆分。
• 選key很重要，既要考慮到拆分均勻，也要考慮到非partition key的查詢。
• 只要能滿足需求，拆分規(guī)則越簡單越好。

七、分庫分表示例

示例GitHub地址：https://github.com/littlecharacter4s/study-sharding

特別推薦一個分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒關(guān)注的小伙伴，可以長按關(guān)注一下：
長按訂閱更多精彩▼
如有收獲，點(diǎn)個在看，誠摯感謝