一种可以避免数据迁移的分库分表scale-out扩容方式

目前绝大多数应用采取的两种分库分表规则

1. mod方式
2. dayofweek系列日期方式（所有星期1的数据在一个库/表,或所有?月份的数据在一个库表）

这两种方式有个本质的特点，就是离散性加周期性。

例如以一个表的主键对3取余数的方式分库或分表：

那么随着数据量的增大，每个表或库的数据量都是各自增长。当一个表或库的数据量增长到了一个极限，要加库或加表的时候，
介于这种分库分表算法的离散性，必需要做数据迁移才能完成。例如从3个扩展到5个的时候：

需要将原先以mod3分类的数据，重新以mod5分类，不可避免的带来数据迁移。每个表的数据都要被重新分配到多个新的表
相似的例子比如从dayofweek分的7个库/表,要扩张为以dayofmonth分的31张库/表，同样需要进行数据迁移。

数据迁移带来的问题是

1. 业务至少要两次发布
2. 要专门写工具来导数据。由于各业务之间的差别，很难做出统一的工具。目前几乎都是每个业务写一套
3. 要解决增量、全量、时间点，数据不一致等问题

如何在数据量扩张到现有库表极限，加库加表时避免数据迁移呢？
通常的数据增长往往是随着时间的推移增长的。随着业务的开展，时间的推移，数据量不断增加。（不随着时间增长的情况，
例如某天突然需要从另一个系统导入大量数据，这种情况完全可以由dba依据现有的分库分表规则来导入，因此不考虑这种问题。）

考虑到数据增长的特点，如果我们以代表时间增长的字段，按递增的范围分库，则可以避免数据迁移
例如，如果id是随着时间推移而增长的全局sequence，则可以以id的范围来分库：（全局sequence可以用tddl现在的方式也可以用ZooKeeper实现）
id在 0–100万在第一个库中，100-200万在第二个中，200-300万在第3个中 （用M代表百万数据）