一.分库分表的原因

我个人觉得原因其实很简单：
1.随着单库中的数据量越来越大，相应的，查询所需要的时间也越来越多，而面对MySQL这样的数据库，在进行添加一列这样的操作时会有锁表的操作，期间所有的读写操作都要等待，这个时候，相当于数据的处理遇到了瓶颈
2.其实就是有意外发生的时候，单库发生意外的时候，需要修复的是所有的数据，而多库中的一个库发生意外的时候，只需要修复一个库（当然，也可以用物理分区的方式处理这种问题）

二.分库分表常用的策略

在我网上搜集的过程中，以及自己的实践，得到的分库策略可以简单分为以下几种方式：（如果有不正确的地方，请大家给我指出来，万分感谢）
首先，分为垂直切分和水平切分：
先说垂直切分吧，我的认为是根据业务的不同，将原先拥有很多字段的表拆分为两个或者多个表，这样的代价我个人觉得很大，原来对这应这个表的关系，开始细分，需要一定的重构，而且随着数据量的增多，极有可能还要增加水平切分；
水平切分，数据表结构，将数据分散在多个表中；

简单的示意图的了解一下。
对于垂直切分，好像能说的并不多，说的比较多一点的是水平切分。
水平切分时候，理想的情况是不进行数据迁移，无感知的进行，当然这就需要一点点小小的分库分表的策略。

1.有瑕疵的简单分库分表（按id的大小分库分表）

按照分片键（我们这里就用id表示了）的大小来进行分库分表，如果你的id是自增的，而且能保证在进行分库分表后也是自增的，那么能进行很好的改造，以id大小水平切分，而且极有可能不用迁移数据。

按id大小分库.PNG

2.比较方便的取模分库

一般的取模分库分表是就是将id mod n，然后放入数据库中，这样能够使数据分散，不会有热点的问题，那么，剩下的是，在扩容的时候，是否会有数据迁移的问题，一般的扩容，当然是会有数据迁移的。

取模.PNG

(1)第一种扩容的方式：根据表的数据增加库的数量

首先，我们有一个数据库——DB_0,四张表——tb_0,tb_1,tb_2,tb_3
那么我们现在数据到数据库是这样的:
DB="DB_0"
TB=“tb_"+id%4

当数据增加，需要进行扩容的时候，我增加一个数据库DB_1
DB="DB_"+((id%4)/2)
TB=“tb_"+id%4

(2)第二种扩容的方式：成倍的增加表

首先，我们还是一个数据库——DB_0,两张表——tb_0,tb_1
那么我们现在数据到数据库是这样的:
DB="DB_0"
TB=“tb_"+id%2

假设当我们数据量打到一千万的时候，我们增加一个库，这时需要我们增加两张表tb_0_1,tb_1_1,并且原来的DB_0中库的表tb_1整表迁移到DB_1中，tb_0和tb_0_1放在DB_0中，tb_1和tb_1_1放到DB1中。
DB="DB_"+id%2
tb:
if(id<1千万) { return "tb_" + id % 2 }
else if(id>=1千万) { return "tb_"+ id % 2 + "_1" }

数据的增长不可能到此为止，当增加到两千万的时候，我们需要加库，这个时候，按照这种做法，我们需要增加两个库(DB_2,DB_3)和四张表(tb_0_2,tb_1_2,tb_2_2,tb_3_2)，将上次新增的表整表分别放进两个新的库中，然后每个库里再生成一张新表。
DB:
if(id < 1千万) { return "DB_" + id % 2 }
else if(1千万 <= id < 2千万) { return "DB_"+ id % 2 +2 }
else if(2千万 <= id ) { return "DB_"+ id % 4 }
tb:
if(id < 1千万) { return "tb_" + id % 2 }
else if(1千万 <= id < 2千万) { return "tb_"+ id % 2 +"1" }
else if(id >= 2千万) { return "tb"+ id % 4+"_2" }

值得注意的一点，在id超出范围的时候，该给怎么样的提示是值得思考的。

(3)第二种扩容的方式：一个一个的增加。(我在这里和原文有点出入，大家不看也罢)

上一种方式是成倍的增加，有的时候往往不需要这样，现在我们基于上一个例子的第二阶段(1千万到2千万的阶段)，添加一个库DB_2,新增两张表tb_0_2,tb_1_2;将tb_0和tb_1放在DB_0中，最为旧文件的查询，tb_0_1和和tb_1_1分别放入DB_1和DB_2中，再在这两个库中生成新的表
DB:
if(id < 1千万) { return "DB_0"}
else if(1千万 <= id < 2千万) { return "DB_"+ (id % 2 + 1)
else if(id >= 2千万) {return "DB_"+ id%3}
tb:
if(id < 1千万) { return "tb_" + id%2}
else if(1千万 <= id < 2千万) { return "tb_"+ (id % 2) +”1“
else if(id >= 2千万) {return "DB"+ id%2 +"_0"}

二.分库分表后的考虑

分库分表之后常常会遇到数据分页的问题，这个问题其实解决的办法很多，但是都没有一个完美的方法，总的来说，还是需要妥协，例如在不分库分表前：select * from t_msg order by time offset 200 limit 100 这样的语句，在分库分表的后，我看到的有这样几种处理
方法一：全局视野法（分别从各个库中提取到x+Y的数据量进行排序提取）
将order by time offset X limit Y，改写成order by time offset 0 limit X+Y。
服务层对得到的N*(X+Y)条数据进行内存排序，内存排序后再取偏移量X后的Y条记录。
方法二：业务折衷法-禁止跳页查询
用正常的方法取得第一页数据，并得到第一页记录的time_max。
每次翻页，将order by time offset X limit Y，改写成order by time where time>$time_max limit Y以保证每次只返回一页数据，性能为常量。
方法三：业务折衷法-允许模糊数据（数据分布足够随机的情况下，各分库所有非patition key属性，在各个分库上的数据分布，统计概率情况应该是一致的）
将order by time offset X limit Y，改写成order by time offset X/N limit Y/N。
方法四：二次查询法
将order by time offset X limit Y，改写成order by time offset X/N limit Y；
找到最小值time_min；
between二次查询，order by time between $$time_min and $time_i_max；
设置虚拟time_min，找到time_min在各个分库的offset，从而得到time_min在全局的offset；
得到了time_min在全局的offset，自然得到了全局的offset X limit Y。

最后我想说，不同的业务场景对应不同的策略，不能为了追求最新的东西，而忽略真正的业务场景，这样的得不偿失。任何一件事都具有两面性，就看你如何取舍，放之四海而皆准。不管什么事情都能解决的，所以，遇到问题不要慌。