今天學(xué)習(xí)了數(shù)據(jù)庫分表分庫，感覺記錄下一些東西以便以后的查看。

1、數(shù)據(jù)庫建立索引，可以加快表數(shù)據(jù)的查詢，但是過多的索引，會占用大量的內(nèi)存，維護難度較大，因為索引底層的算法是B-tree,樹的特點就是查找數(shù)據(jù)快按時數(shù)據(jù)增刪改比較慢。

2、數(shù)據(jù)庫的表拆分，分為水平拆分，垂直拆分，水平垂直拆分（自定義的）。

3、mycat：數(shù)據(jù)庫的中間件，數(shù)據(jù)庫的代理，屏蔽物理數(shù)據(jù)庫的，支持多種拆分結(jié)構(gòu)。

一、水平拆分：（部分摘自：https://www.cnblogs.com/firstdream/p/6728106.html）

1）、把同一個表拆到不同的數(shù)據(jù)庫中。

2）、垂直拆分后遇到單機瓶頸，可以使用水平拆分。

3）、水平拆分不是將表的數(shù)據(jù)做分類，而是按照某個字段的某種規(guī)則來分散到多個庫之中，每個表中包含一部分?jǐn)?shù)據(jù)。簡單來說，我們可以將數(shù)據(jù)的水平切分理解為是按照數(shù)據(jù)行的切分，就是將表中 的某些行切分到一個數(shù)據(jù)庫，而另外的某些行又切分到其他的數(shù)據(jù)庫中，主要有分表，分庫兩種模式，如圖：

?

優(yōu)點： 1. 不存在單庫大數(shù)據(jù)，高并發(fā)的性能瓶頸。 2. 對應(yīng)用透明，應(yīng)用端改造較少。 ? ?? 3. 按照合理拆分規(guī)則拆分，join操作基本避免跨庫。 4. 提高了系統(tǒng)的穩(wěn)定性跟負載能力。 5. 切分策略簡單，根據(jù)uid，按照范圍，user- center很快能夠定位到數(shù)據(jù)在哪個庫上， 擴容簡單，如果容量不夠，只要增加數(shù)據(jù)庫即可（用戶表實際場景） 缺點： 1.?拆分規(guī)則難以抽象。 2. 分片事務(wù)一致性難以解決。 3. 數(shù)據(jù)多次擴展難度跟維護量極大。 4. 跨庫join性能較差。 5.數(shù)據(jù)量不均，新增的user-db3，在初期的數(shù)據(jù)會比較少， 請求量不均，一般來說，新注冊的用戶活躍度會比較高，故user-db2往往會比user-db1負載要高，導(dǎo)致服務(wù)器利用率不平衡。（用戶表的實際場景）

二、垂直拆分：

1）、垂直拆分是把不同的表拆到不同的數(shù)據(jù)庫中。

2）、按照業(yè)務(wù)將表進行分類，分布到不同的數(shù)據(jù)庫上面，這樣也就將數(shù)據(jù)或者說壓力分擔(dān)到不同的庫上面。

優(yōu)點： 1. 拆分后業(yè)務(wù)清晰，拆分規(guī)則明確。 2. 系統(tǒng)之間整合或擴展容易。 3. 數(shù)據(jù)維護簡單。 缺點： 1. 部分業(yè)務(wù)表無法join，只能通過接口方式解決，提高了系統(tǒng)復(fù)雜度。 2. 受每種業(yè)務(wù)不同的限制存在單庫性能瓶頸，不易數(shù)據(jù)擴展跟性能提高。 3. 事務(wù)處理復(fù)雜。 三 、數(shù)據(jù)庫切分方法|哈希法 優(yōu)點： ?切分策略簡單，根據(jù)uid，按照范圍，快速定位到分布的數(shù)據(jù)庫中。 ?數(shù)據(jù)量均衡：只要uid是均衡的，數(shù)據(jù)分布在各個庫是均衡的。 ?請求量均衡：只要uid是均衡的，每個庫負載也相對是均衡的。 缺點： 1、擴容麻煩，如果需要增加一個庫，需要重新hash，這有可能會導(dǎo)致數(shù)據(jù)遷移，給平滑升級帶來困難。 四、真實的業(yè)務(wù)場景：

1）、訂單中心數(shù)據(jù)庫切分方法|數(shù)據(jù)冗余法（部分參考原文：https://blog.csdn.net/sunhuiliang85/article/details/78418546?）

互聯(lián)網(wǎng)數(shù)據(jù)量很大的業(yè)務(wù)場景，往往數(shù)據(jù)庫需要進行水平切分來降低單庫數(shù)據(jù)量。?

水平切分會有一個patitionkey，通過patition key的查詢能夠直接定位到庫，但是非patitionkey上的查詢可能就需要掃描多個庫了。?

此時常見的架構(gòu)設(shè)計方案，是使用數(shù)據(jù)冗余這種反范式設(shè)計來滿足分庫后不同維度的查詢需求。

訂單表可以中可以存訂單編號，賣家的編號，買家的編號，同時再以買家編號為主鍵建立買家表，再以賣家編號為主鍵建立賣家表。

?

轉(zhuǎn)載于:https://www.cnblogs.com/takemyjavalisfe/p/10079868.html

總結(jié)

以上是生活随笔為你收集整理的数据库分库分表（持续更新中）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。