在实际的应用场景中，除了那些负载并不是太大、业务逻辑也相对简单的系统可以通过上面切分方法之一来解决扩展性问题之外，恐怕其他大部分业务逻辑复杂、系统负载大的系统，都无法通过上面任何一种数据的切分方法来实现较好的扩展性，这就需要将“垂直”和“水平”这两种切分方法结合使用，不同的场景使用不同的切分方法。

    一般来说，数据库中的所有表很难通过某一个（或少数几个）字段全部关联起来，所以仅仅通过数据的水平切分无法解决所有问题。而垂直切分也只能解决部分问题，对于那些负载非常高的系统，即使只是单个表都无法通过单台数据库主机来承担其负载。必须结合“垂直”和“水平”两种切分方式，充分利用两者的优点，避开其缺点。

    每一个应用系统的负载都是一步一步增长上来的，在开始遇到性能瓶颈的时候，大多数架构师和DBA都会选择先进行数据的垂直拆分，因为这样的成本最低，最符合这个时期所追求的最大投入产出比。然而，随着业务的不断扩张，系统负载的持续增长，在系统稳定一段时期之后，经过了垂直拆分之后的数据库集群可能再次不堪重负，遇到了性能瓶颈。

    此时该如何抉择？是再次进一步细分模块，还是寻找其他的解决办法？如果我们再像最开始那样继续细分模块，进行数据的垂直切分，那可能在不久的将来，又会遇到现在所面临的同样问题。而且随着模块的不断细分，应用系统的架构也会越来越复杂，整个系统很可能会出现失控的局面。

    这时候就需要利用数据水平切分的优势来解决遇到的问题。而且，完全不必在使用数据水平切分时，推倒之前进行数据垂直切分的成果，而是在其基础上利用水平切分的优势来避开垂直切分的弊端，解决系统复杂性不断扩大的问题。而水平拆分的弊端（规则难以统一）也已经被之前的垂直切分解决掉了，让水平切分可以进行得得心应手。

    实际上，在很多大型的应用系统中，垂直切分和水平切分基本上是并存的，而且经常在不断地交替进行，以增加系统的扩展能力。我们在应对不同的应用场景时，也需要充分考虑到这两种切分方法的局限及优势，在不同时期（负载压力）使用不同的方式。

    联合切分的有点：

    1）可以充分利用垂直切分和水平切分各自的优势而避免各自的缺陷；

    2）让系统扩展性得到最大化提升。

    联合切分的缺点：

    1）数据库系统架构比较复杂，维护难度更大；

    2）应用程序架构也更复杂。