垂直切分的粒度指的是在做垂直切分時允許幾級的關聯表放在一個shard裡．這個問題對應用程式和sharding實現有著很大的影響．

關聯打斷地越多，則受影響的join操作越多，應用程式為此做出的妥協就越大，但單表的路由會越簡單，與業務的關聯性會越小，就越容易使用統一機制處理．在此方向上的極端方案是：打斷所有連線，每張表都配有路由規則，可以使用統一機制或框架自動處理．比如amoeba這樣的框架，它的路由能且僅能通過SQL的特徵（比如某個表的id）進行路由．

反之，若關聯打斷地越少，則join操作的受到的限制就小，應用程式需要做出的妥協就越小，但是表的路由就會變複雜，與業務的關聯性就越大，就越難使用統一機制處理，需要針對每個資料請求單獨實現路由．在此方向上的極端方案是：所有表都在一個shard裡，也就是沒有垂直切分，這樣就沒有關聯被打斷．當然這是非常極端的，除非整個資料庫很簡單，表的數量很少．

實際的粒度掌控需要結合“業務緊密程度”和“表格資料量”兩個因素綜合考慮，一般來說：

• 若劃歸到一起的表格關係緊密，且資料量並不大，增速也非常緩慢，則適宜放在一個shard裡，不需要再進行水平切分;

• 若劃歸到一起的表格資料量巨大且增速迅猛，則勢必要在垂直切分的基礎上再進行水平切分，水平切分就意味著原單一shard會被細分成多個更小的shard，每一個shard存在一個主表（即會以該表ID進行雜湊的表）和多個相之相關的關聯表。

總之，垂直切分的粒度在兩個相反的方向上呈現優勢與劣勢並存並相互博弈的局面．架構師需要做的是結合專案的實際情況在兩者之間取得收益最大化的平衡．

相關閱讀：