分库分表

1）使用场景

对于Mysql主从复制实现读写分离来说，可以解决读的扩展性问题。但是写的话，面对庞大的数据量还是集中在Master上，并且Master挂载的slave不可能无限制多，因为slave依赖于Master的能力和负载的限制。因此需要对Master进行扩展来实现海量数据的需要。

2）分表

对于访问极为频繁，数据量又极大的表来说，最直接做的就是减少数据量的总条数，以便减少数据查询所需要的时间，可以对大数据表进行分表。

分表策略：用id来进行分表是最为常见的策略，因为大部分查询都要带上id，又不影响查询又能使得数据均衡的分布在各个表中。假设有一个订单表有1000w条数据，将该表分成16个表，将id%16进行存储，如果id不是数字可以先hash取值。拆分的记录根据取余的值进行存储，App应用根据取余的值进行表的访问。

3）分库

分表能解决数据量过大造成的查询效率低下的问题，但是无法有效提示数据的并发访问能力。将数据库拆分，提高数据库的写入能力就是所谓的分库。

与分表类似，分库策略可以通过对某一个字段如id进行取余操作，来对数据访问进行路由。如id=19，分成3个库，19%3=1，这时候就路由到第一个库。

4）分库分表

既要面临大数据的问题，又要面临高并发访问的问题。

    分库分表的策略比前面的仅分库或者仅分表的策略要更为复杂，一种分库分表的路由策略如下：

    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表中执行！！！