上面一节分析介绍了数据的垂直切分，本节分析数据的水平切分。数据的垂直切分基本上可以简单地理解为按照表或模块来切分数据，而水平切分则不同。一般来说，简单的水平切分主要是将某个访问极其平凡的表再按照某个字段的某种规则分散到多个表中，每个表包含一部分数据。

简单来说，可以将数据的水平切分理解为按照数据行的切分，就是将表中的某些行切分到一个数据库，而另外的某些行又切分到其他的数据库中。当然，为了能够比较容易地判定各行数据被切分到哪个数据库中了，切分总是须要按照某种特定的规则来进行的：如根据某个数字类型字段基于特定数目取模，某个时间类型字段的范围，或者某个字符类型字段的 hash 值。如果整个系统中大部分核心表都可以通过某个字段来进行关联，那这个字段自然是一个进行水平分区的上上之选了，当然，非常特殊无法使用的情况除外。

一般来说，像现在非常火爆的 Web 2.0 类型网站，基本上大部分数据都能够通过会员用户信息关联上，可能很多核心表都非常适合通过会员 ID 来进行数据的水平切分。而像论坛社区讨论系统，就更容易切分了，可以按照论坛编号来进行水平切分。切分之后基本上不会出现各个库之间的交互。

如果示例系统的所有数据都是和用户关联的，那么就可以根据用户来进行水平拆分，将不同用户的数据切分到不同的数据库中。当然，唯一区别是用户模块中的 groups 表和用户没有直接关系，所以 groups 不能根据用户来进行水平拆分。对于这种特殊情况下的表，完全可以独立出来，放在一个独立的数据库中。其实这个做法可以说是利用了前面一节所介绍的"数据的垂直切分"方法，将在下一节中更为详细地介绍这种垂直切分与水平切分同时使用的联合切分方法。

所以，对于示例数据库来说，大部分的表都可以根据用户 ID 来进行水平切分。不同用户相关的数据进行切分之后存放在不同的数据库中。如将所有用户 ID 通过被2 取模然后分别存放于两个不同的数据库中。每个和用户 ID 关联上的表都可以这样切分。这样，基本上每个用户相关的数据，都在同一个数据库中，即使须要关联，也非常容易实现。

可以通过水平切分示意图

水平切分的优点：

表关联基本能够在数据库端全部完成；

不会存在某些超大型数据量和高负载的表遇到瓶颈的问题；

应用程序端整体架构改动相对较少；

事务处理相对简单；

只要切分规则能够定义好，基本上较难遇到扩展性限制。

水平切分的缺点：

切分规则相对复杂，很难抽象出一个能够满足整个数据库的切分规则；

后期数据的维护难度有所增加，人为手工定位数据更困难；

应用系统各模块耦合度较高，可能会对后面数据的迁移拆分造成一定的困难。