今天學習了數據庫分表分庫，感覺記錄下一些東西以便以后的查看。

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

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

3、mycat：數據庫的中間件，數據庫的代理，屏蔽物理數據庫的，支持多種拆分結構。

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

1）、把同一個表拆到不同的數據庫中。

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

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

?

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

二、垂直拆分：

1）、垂直拆分是把不同的表拆到不同的數據庫中。

2）、按照業務將表進行分類，分布到不同的數據庫上面，這樣也就將數據或者說壓力分擔到不同的庫上面。

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

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

互聯網數據量很大的業務場景，往往數據庫需要進行水平切分來降低單庫數據量。?

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

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

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

?

轉載于:https://www.cnblogs.com/takemyjavalisfe/p/10079868.html

總結

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

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