1.為什么需要分區(qū)分表分庫

數(shù)據(jù)量達到一定規(guī)模，進行常規(guī)的sql語句優(yōu)化已經(jīng)效果不大的情況下，常見為mysql數(shù)據(jù)庫，單表的記錄達到1000W和空間占用至100G，可以擴充硬件，但是硬件收益已經(jīng)不大的情況下，或者在預算有限的情況下，則需要進行優(yōu)化數(shù)據(jù)庫結構。這個時候就應該對數(shù)據(jù)進行拆分。

2.各種分區(qū)分表分庫的情況

1.分區(qū)
分區(qū)是數(shù)據(jù)庫本身的一個特性功能，將數(shù)據(jù)按照業(yè)務拆分成多個區(qū)，在業(yè)務上先判斷屬于哪個分區(qū)即可到指定分區(qū)查詢，這樣就可實現(xiàn)更快的查詢速度了。
2.垂直分表
一個表的字段過多，根據(jù)實際業(yè)務訪問獲取數(shù)據(jù)的字段，將其拆分成兩個表，就類似于副表，相當于單表轉為一對一，如商品訂單詳情表，將訂單的時間，商品各種基本信息作為主表，相對不重要的東西，或者需要點擊多一步的東西作為副本表，通過增加訪問接口的形式實現(xiàn)加速。
3.垂直分庫
垂直分庫，可根據(jù)業(yè)務，將有一定關系，但是耦合度不算高的表放到不同服務器的庫中，變相增強硬件，各個庫各司其職。比如商品庫，店鋪庫等等
4.水平分庫
一般優(yōu)先垂直分庫，之后再進行水平分庫，常見商品庫里，商品的記錄很多，單表1500W+，可將原本的DB，變?yōu)镈B1,DB2，結構一致，將數(shù)據(jù)根據(jù)id，進行%2+1然后分別插入（算法可以自定義），這樣一個庫就只有750W了，弊端數(shù)據(jù)庫實例過多，導致運營維護不便。還有一種情況是做讀寫分離。
5.水平分表
同理水平分庫，只是放在同一個實例，拆分維度由庫變成表，可以對庫里的數(shù)據(jù)一張表分為結構一致的多張表表，比如tb1,tb2,可以一樣將數(shù)據(jù)根據(jù)id，進行%2+1進行保存（算法可以自定義），也可以將數(shù)據(jù)按照日期進行存儲拜訪，比如一個月，一年為維度等等。

3.弊端

3.1分區(qū)弊端

依賴于數(shù)據(jù)庫特性，需要在sql明確知道屬于哪個分區(qū)，相對來說基本屬于硬編碼，本質還是使用的一個數(shù)據(jù)庫實例，吞吐量還是有限。且如果要分頁展示難以實現(xiàn)跳頁功能，需簡化分頁，比如使用流式或者只能上一頁下一頁這樣的功能的分頁效果。

3.2分表分庫弊端

1.事務問題，由于實例分同一個，存在分布式事務問題
2.關聯(lián)查詢節(jié)點不同，如店鋪和商品庫，需要使用業(yè)務代碼處理
3分頁問題，升降序處理
4.實例或表不同，無法使用自增主鍵，會出現(xiàn)主鍵沖突，uuid不是趨勢遞增，難以使用id進行進行分庫，需要一些分布式id的解決方案，比如雪花算法等等
5.公共表，一般數(shù)據(jù)量不是特別大，但是和各個業(yè)務聯(lián)系相對緊密，如地區(qū)，常見做法，將地區(qū)表每個實例放一份，但是同步增刪改是一個麻煩的事情