杭州甲骨文OAEC提醒：如果数据库需要进行水平拆分，这其实是一件很开心的事情，因为它代表公司的业务正在迅勐的增长，对于开发人员而言那就是有不尽的项目可以做，虽然会感觉很忙，但是人过的充实，心里也踏实。数据库水平拆分简单说来就是先将原数据库里的一张表在做垂直拆分出来放置在单独的数据库和单独的表里后更进一步的把本来是一个整体的表进一步拆分成多张表，每一张表都用独立的数据库进行存储。当表被水平拆分后，原数据表成为了一个逻辑的概念，而这个逻辑表的业务含义需要多张物理表协同完成，因此数据库的表被水平拆分后，那么我们对这张表的操作已经超出了数据库本身提供给我们现有的手段，换句话说我们对表的操作会超出数据库本身所拥有的处理能力，这个时候我就需要设计相关的方案来弥补数据库缺失的能力，这就是数据库水平拆分较大的技术难点所在。

　　数据库的水平拆分是数据库垂直拆分的升级版，它和垂直拆分更像继承机制里的父子关系，因此水平拆分后，垂直拆分所遇到的join查询的问题以及分布式事务的问题任然存在，由于表被物理拆解增加了逻辑表的维度，这也给垂直拆分里碰到的两个难题增加了更多的维度，因此水平拆分里join查询的问题和分布式事务会变得更加复杂。水平拆分除了垂直拆分两个难题外，它还会产生新的技术难题，这些难题具体如下：

　　难题一：数据库的表被水平拆分后，该表的主键设计会变得十分困难；

　　难题二：原来单表的查询逻辑会面临挑战。

　　在准备本篇文章时候，杭州诺博源看到一些资料里还提到了一些难题，这些难题是：

　　难题三：水平拆分表后，外键的设计也会变得十分困难；

　　难题四：这个难题是针对数据的新增操作的，大致的意思是，我们到底按什么规则把需要存储的数据存储在拆分出的那个具体的物理数据表里。

　　难题三的问题，杭州诺博源在上篇已经给出了解答，这里我进行一定的补充，其实外键问题在垂直拆分就已经存在，不过在讲垂直拆分时候我们没有讲到这个问题，这主要是我设定了一个前提，就是数据表在较原始的数据建模阶段就要抛弃所有外键的设计，并将外键的逻辑抛给服务层去完成，我们要尽全力减轻数据库承担的运算压力，其实除了减轻数据库运算压力外，我们还要将作为存储原子的表保持相对的独立性，互不关联，那么要做到这点较直接的办法就是去掉表与表之间关联的象征：外键，这样我们就可以从根基上为将来数据库做垂直拆分和水平拆分打下坚实的基础。

　　至于难题四，其实问题的本质是分库分表后具体的数据在哪里落地的问题，而数据存储在表里的关键障碍其实就是主键，试想一下，我们设计张表，所有字段我们都准许可以为空，但是表里有个字段是不能为空的，那就是主键，主键是数据在数据库里身份的象征，因此我们在主键设计上是可以体现出该数据的落地规则，那么难题四也会随之解决。因此下文我会重点讲解前两个水平拆分的难题。

　　杭州数据库培训：http://hzjgwit.soxsok.com/；手机网址 http://m.soxsok.com/hzjgwIT/