垂直切分的粒度指的是在做垂直切分时允许几级的关联表放在一个shard里．这个问题对应用程序和sharding实现有着很大的影响．
关联打断地越多，则受影响的join操作越多，应用程序为此做出的妥协就越大，但单表的路由会越简单，与业务的关联性会越小，就越容易使用统一机制处理．在此方向上的极端方案是：打断所有连接，每张表都配有路由规则，可以使用统一机制或框架自动处理．比如amoeba这样的框架，它的路由能且仅能通过SQL的特征（比如某个表的id）进行路由．
反之，若关联打断地越少，则join操作的受到的限制就小，应用程序需要做出的妥协就越小，但是表的路由就会变复杂，与业务的关联性就越大，就越难使用统一机制处理，需要针对每个数据请求单独实现路由．在此方向上的极端方案是：所有表都在一个shard里，也就是没有垂直切分，这样就没有关联被打断．当然这是非常极端的，除非整个数据库很简单，表的数量很少．
实际的粒度掌控需要结合“业务紧密程度”和“表格数据量”两个因素综合考虑，一般来说：
若划归到一起的表格关系紧密，且数据量并不大，增速也非常缓慢，则适宜放在一个shard里，不需要再进行水平切分; 若划归到一起的表格数据量巨大且增速迅猛，则势必要在垂直切分的基础上再进行水平切分，水平切分就意味着原单一shard会被细分成多个更小的shard，每一个shard存在一个主表（即会以该表ID进行散列的表）和多个相之相关的关联表。总之，垂直切分的粒度在两个相反的方向上呈现优势与劣势并存并相互博弈的局面．架构师需要做的是结合项目的实际情况在两者之间取得收益最大化的平衡．
相关阅读：
bluishglc 认证博客专家 博客专家 架构师，博客专家，14年IT系统开发和架构经验，对大数据、企业级应用架构、SaaS、分布式存储和领域驱动设计有丰富的实践经验。对Hadoop/Spark 生态系统有深入和广泛的研究，参与过Hadoop商业发行版的开发，目前负责企业数据中台的架构设计和开发工作，热衷函数式编程，著有《大数据平台架构与原型实现：数据中台建设实战》https://item.jd.com/12677623.html 一书。
