分庫分表(這里不討論中間件)

分庫：原因：單機負載高，優點：降低單機負載
分表：原因：單表讀寫壓力大或者數據增長快，優點：使用多個表，提高讀寫效率
1、(代碼)分表，即把一個很大的表達數據分到幾個表中，這樣每個表數據都不多。
???? ? ? ? ? ??? 優點：提高并發量，減小鎖的粒度
???????????????? 缺點：代碼維護成本高，相關sql都需要改動

2、(mysql)分區，所有的數據還在一個表中，但物理存儲數據根據一定的規則存放在不同的文件中，文件也可以放到另外磁盤上
??? ? ? ? ? ? ?? ?? 優點：代碼維護量小，基本不用改動，提高IO吞吐量
??? ? ? ? ? ? ? ? ? 缺點：表的并發程度沒有增加

分表：
在一個庫中進行進行分表，有兩種方法
1、mysql表分區 （推薦）
使用表分區時，分區字段。需要根據業務來定，這里所說的業務，指的就是需要做分表的表會和哪些業務相關，
比如訂單表，主鍵是訂單ID，分表時，需要結合業務綜合看待。
單純就技術看：
如果按訂單ID進行hash，操作分布多個表，但是在拓展時，就很麻煩
如果按訂單ID進行范圍range，操作集中某幾個表，拓展時，很方便
綜合結合看：
a，當業務需要根據時間來查詢
如果按訂單ID進行表分區，那么會造成查詢無法走索引，導致全表掃描，效率低下，
如果按時間ID進行表分區，查詢會走索引，但是時間都是按范圍range，操作會集中幾個表，讀寫壓力就很明顯
b，當業務需要查詢用戶某一時間段的訂單
c，當業務需要.....
需要把所有業務都考慮進去

2、分表
分表的做法和表分區相同，不同的是需要在代碼中實現這個功能。做法是先建立分表，然后在程序中寫分表代碼邏輯。
比如需要對訂單表分表，代碼中就會按訂單ID（也可以任何字段）進行范圍、或者hash取余計算該訂單ID所處于的表，如果使用hash,可以使用一致性hash分表，避免hash取模方式在表增刪時遷移全部數據。
同樣，分表也需要集合業務，而且更加麻煩
單純就技術看：
如果按訂單ID進行hash，操作分布多個表，但是在拓展時，就很麻煩，需要把原來的數據再重新導入所有節點，這里很消耗時間，關鍵是導致系統很長的不可用時間
如果按訂單ID進行范圍range，操作集中某幾個表，拓展時，很方便
這里和表分區的技術優缺點相同。
綜合結合看：
a，當業務需要根據時間來查詢
如果按訂單ID進行表分區，無論是范圍，還是Hash，都無法根據時間進行查詢，只有全表掃描
如果按時間ID進行表分區，基本是按范圍分表，可以定位時間范圍。但是業務肯定會用訂單ID來查詢，而代碼是根據時間ID做范圍分表，等于說根據訂單ID查詢的業務就不可用了。
b，當業務需要查詢用戶某一時間段的訂單
c，當業務需要.....
需要把所有業務都考慮進去


從這里可以看到，單純做庫內的分表，mysql自帶的表分區適應度更高，分表的做法只適合于沒有復雜的業務、多維度的查詢。
一定要和業務結合起來，不然會遇到分了表后，業務無法運行的尷尬場面。

分庫：
在數據庫中進行進行分庫，有兩個辦法
1、代碼分庫
在代碼中進行范圍、或者hash取余計算該訂單ID所處于的庫，如果使用hash,最好是一致性hash分庫，避免hash取模方式在節點增刪時遷移全部數據。
單純就技術看：
優點：計算簡單，
缺點：增刪庫時，需要修改代碼，并且需要遷移數據
2、單獨建庫建表，存放數據對應位置
單純就技術看：
優點：可拓展性強
缺點：多次查詢，效率低下，數據是否遷移看業務

綜合結合看：
無論代碼分庫還是表存放位置，都存在跨庫查詢，已經分布式事務的問題，這里一定要綜合業務，梳理流程，避免分布式事務。

分庫分表：
在數據庫中進行進行分庫分表，有兩個辦法
1、代碼分庫
a、代碼分庫+表分區
像這種組合的分庫，一定要考慮到后期拓展的問題，如果是按范圍，就沒問題，直接增庫，如果是按hash，就需要把所有的數據全部導出，再導入，時間代價很大。
優點：只需一層計算數據位置，表分區管理簡單
缺點：需要遷移數據時，表分區較麻煩
這里沒有寫一致性hash分庫+表分區，因為組合不能起到應有的效果。例如，分庫使用一致性Hash，而表分區是hash，兩邊的算法不一致，數據無法對應， 就只能全部遷移了。
b、代碼分庫+分表
一種是hash分庫 + hash分表，這個方法和上面的a方法相比，拓展時的都存在數據遷移時間過長，不同的是，a方法的表分區管理起來更簡單。
一種是一致性hash分庫 + 一致性hash分表，相比較，一致性Hash不易理解，有難度，遷移需要玩完備的方案，很繁瑣，但是拓展時，只需要遷移部分數據即可。
優點：自由度高
缺點：多層計算，維護難度大
這里沒有寫一致性hash和hash分表的組合，因為一致性hash要求算法一致。如果算法不同，在數據遷移時，很可能就會遷移全部數據，甚至數據混亂。
2、建庫建表，存放數據對應的DB位置和表位置
注意：
分庫分表中可能遇到跨庫查詢或者分布式事務的問題，比如用戶ID為1的數據在庫A，用戶1的訂單數據在庫B，可以將用戶1的關聯訂單數據在插入時選擇用戶1所在的庫A，這樣就能避免分布式查詢和事務的問題。

來源:http://blog.csdn.net/stubborn_cow/article/details/50781310

總結

以上是生活随笔為你收集整理的mysql分库分表方案浅析的全部內容，希望文章能夠幫你解決所遇到的問題。

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