分库分表使用场景及设计方式

一. 分表

      场景：对于大型的互联网应用来讲，数据库单表的记录行数可能达到千万级甚至是亿级，而且数据库面临着极高的并发访问。采用Master-Slave复制模式的MySQL架构，只可以对数据库的读进行扩展，而对数据库的写入操做仍是集中在Master上，而且单个Master挂载的Slave也不可能无限制多，Slave的数量受到Master能力和负载的限制。

　　所以，须要对数据库的吞吐能力进行进一步的扩展，以知足高并发访问与海量数据存储的须要！

　　对于访问极为频繁且数据量巨大的单表（百万到千万级别）来讲，咱们首先要作的就是减小单表的记录条数，以便减小数据查询所须要的时间，提升数据库的吞吐，这就是所谓的分表！

　　在分表以前，首先须要选择适当的分表策略，使得数据可以较为均衡地分不到多张表中，而且不影响正常的查询！ 

　　对于互联网企业来讲，大部分数据都是与用户关联的，所以，用户id是最经常使用的分表字段。由于大部分查询都须要带上用户id，这样既不影响查询，又可以使数据较为均衡地分布到各个表中(固然，有的场景也可能会出现冷热数据分布不均衡的状况)，以下图：

　　假设有一张表记录用户购买信息的订单表order，因为order表记录条数太多，将被拆分红256张表。

　　拆分的记录根据user_id%256取得对应的表进行存储，前台应用则根据对应的user_id%256，找到对应订单存储的表进行访问。（即id除以256余数为0则查0号表）

　　这样一来，user_id便成为一个必需的查询条件，不然将会因为没法定位数据存储的表而没法对数据进行访问。

　　注：拆分后表的数量通常为2的n次方，就是上面拆分红256张表的由来！

举例：

假设order表结构以下：

 1 create table order_(
 2  order_id bigint(20) primary key auto_increment,
 3  user_id bigint(20),
 4  user_nick varchar(50),
 5  auction_id bigint(20),
 6  auction_title bigint(20),
 7  price bigint(20),
 8  auction_cat varchar(200),
 9  seller_id bigint(20),
10  seller_nick varchar(50)
11 )

　　那么分表之后，假设user_id = 257,而且auction_id = 100,须要根据auction_id来查询对应的订单信息，则对应的SQL语句以下：

select * from order_1 where user_id=257 and auction_id = 100;

　　其中，order_1是根据257%256计算得出，表示分表以后的第一张order表。

二. 分库

　　场景：分表可以解决单表数据量过大带来的查询效率降低的问题，可是，却没法给数据库的并发处理能力带来质的提高。面对高并发的读写访问，当数据库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表中执行！！！

四，横分纵分

分表又分为横向分表和纵向分表

1）纵向分表

　　 将原本能够在同一个表的内容，人为划分为多个表。（所谓的原本，是指按照关系型数据库的 第三范式要求，是应该在同一个表的。）

分表理由： 根据数据的活跃度进行分离，（由于不一样活跃的数据，处理方式是不一样的）

 

案例：

　　对于一个博客系统，文章标题，做者，分类，建立时间等，是 变化频率慢， 查询次数多，并且最好有很好的实时性 的数据，咱们把它叫作 冷数据。而博客的浏览量，回复数等，相似的统计信息，或者别的 变化频率比较高的数据，咱们把它叫作 活跃数据。因此，在进行数据库结构设计的时候，就应该考虑分表，首先是 纵向分表的处理。

这样纵向分表后：

　　首先存储引擎的使用不一样， 冷数据使用MyIsam 能够有更好的查询数据。 活跃数据，可使用Innodb,能够有更好的更新速度。

　　其次， 对冷数据进行更多的 从库配置，由于更多的操做时查询，这样来加快查询速度。 对热数据，能够相对有更多的 主库的横向分表处理。

　　其实，对于一些 特殊的活跃数据，也能够考虑使用memcache , redis之类的缓存，等累计到 必定量再去更新数据库。或者mongodb 一类的nosql数据库，这里只是举例，就先不说这个。

横向分表

　　字面意思，就能够看出来，是把大的表结构，横向切割为一样结构的不一样表，如，用户信息表，user_1,user_2等。 表结构是彻底同样，可是，根据某些特定的规则来划分的表，如根据用户ID来取模划分。

　　分表理由： 根据数据量的规模来划分，保证单表的容量不会太大，从而来保证单表的查询等处理能力。

案例：

　　同上面的例子，博客系统。当博客的量达到很大时候，就应该采起横向分割来下降每一个单表的压力，来提高性能。例如博客的冷数据表，假如分为100个表，当同时有100万个用户在浏览时，若是是单表的话，会进行100万次请求，而如今分表后，就多是每一个表进行1万个数据的请求（由于，不可能绝对的平均，只是假设），这样压力就下降了不少不少。

 

https://blog.csdn.net/yuxianjun2012/article/details/54846136 

https://blog.csdn.net/winy_lm/article/details/50708493