首先说说我们为什么需要数据库分表？
对于大型的互联网应用来说，数据库的单表记录可达到千万级甚至亿级，并且数据还需承受极高的并发访问。采用,Master-slave的主从复制模式的MySql架构只能对数据库的读进行扩展，而对数据库的写入操作还是集中在Master上，并且单个Master挂载的Slave也不可能无限制多，Slave的数量受到Master能力和负载的限制。因此，需要对数据库的吞吐能力进行进一步的扩展，以满足高并发访问与海量数据存储的需要！
对于频繁访问且数据量巨大的单表来说，我们首先要做的就是减少单表的记录条数，以便减少单表的查询需要的时间，提高数据库的吞吐量，这就是所谓的分表。
那么问题来了！！
我们应该如何分表，才能使得数据均匀的分布到多张表中，并且不影响查询。
于互联网企业来说，大部分数据都是与用户关联的，因此，用户id是最常用的分表字段。因为大部分查询都需要带上用户id，这样既不影响查询，又能够使数据较为均衡地
分布到各个表中(当然，有的场景也可能会出现冷热数据分布不均衡的情况)
假设有一张表记录用户购买信息的订单表order，由于order表记录条数太多，将被拆分成256张表。
拆分的记录根据user_id%256取得对应的表进行存储，前台应用则根据对应的user_id%256，找到对应订单存储的表进行访问。
这样一来，user_id便成为一个必需的查询条件，否则将会由于无法定位数据存储的表而无法对数据进行访问。
注：拆分后表的数量一般为2的n次方，就是上面拆分成256张表的由来！
这里我们实现了分表来减轻单表因数据量过大带来的效率低下的问题，但是无法给数据库的并发处理能力带来质的提升。
面对高并发的读写访问，当数据库master
服务器无法承载写操作压力时，不管如何扩展slave服务器，此时都没有意义了。
因此，我们必须换一种思路，对数据库进行拆分，从而提高数据库写入能力，这就是所谓的分库。。。。
与分表策略相似，分库可以采用通过一个关键字取模的方式，来对数据访问进行路由，如下图所示：
还是之前的订单表，假设user_id 字段的值为258，将原有的单库分为256个库，那么应用程序对数据库的访问请求将被路由到第二个库(258%256 = 2)。
三. 分库分表
有时数据库可能既面临着高并发访问的压力，又需要面对海量数据的存储问题，这时需要对数据库既采用分表策略，又采用分库策略，以便同时扩展系统的
并发处理能力，以及提升单表的查询性能，这就是所谓的分库分表。
分库分表的策略比前面的仅分库或者仅分表的策略要更为复杂，一种分库分表的路由策略如下：
1. 中间变量 = user_id % (分库数量 * 每个库的表数量)
2. 库 = 取整数 (中间变量 / 每个库的表数量)
3. 表 = 中间变量 % 每个库的表数量
这时我们引入一个中间变量来帮忙完成分表分库的策略。同样使用user_id作为路由的字段。使用user_id来对数据库的数量和每个库的表数量去模得到一个中间变量，然后使用中间变量对除以每个库表的数量取整得到库，而中间变量对每个库表的数量取模，即得到对应的表。
分库分表策略详细过程如下：
假设将原来的单库单表order拆分成256个库，每个库包含1024个表，那么按照前面所提到的路由策略，对于user_id=262145 的访问，路由的计算过程如下：
1. 中间变量 = 262145 % (256 * 1024) = 1
2. 库 = 取整 (1/1024) = 0
3. 表 = 1 % 1024 = 1
这就意味着，对于user_id=262145 的订单记录的查询和修改，将被路由到第0个库的第1个order_1表中执行！！！