面试官：如何来设计动态扩容的分库分表方案？
面试官心理剖析：
这个问题主要是看看你们公司设计的分库分表设计方案怎么样的？你知不知道动态扩容的方案？
回答：
背景说明：如果你们公司之前已经做了分库分表，你们当时分了 4 个库，每个库 4 张表；公司业务发展的很好，现在的数据库已经开始吃力了，不能满足快速发展的业务量了，需要进行扩容。
1）停机扩容
这个方案跟单库迁移方案是一样的，就是停服进行数据迁移，不过现在的数据迁移比之前的单库迁移要复杂的多，还有数据量也是之前的好几倍，单库的数据量可能就几千万，但是现在是 12 个表，那么数据量是几十亿，可能光数据迁移就要花上好几个小时，等你的数据迁移完就已经上凌晨 5 点了，验证完可能都早上 9 点了，这样肯定是不行的，除非第二天你的系统还不能提供服务，那么用户来访问的时候，你们还在升级，这样你们公司就会损失很多钱。
2）双写扩容
这个方案也会变的很复杂，你的数据迁移工具也会写的很复杂。
3）动态扩容方案
比如你直接分 32 个库，每个库分 32 个表；
每个库的每秒写入并发是 2000，单表的数据量为 700 万；
每秒写并发：32 个库2000=64000
数据量：1024 个表7000000=7168000000
如果你觉得你们公司的业务量发展会远远大于这个，那么可以直接扩容到更多的库。
刚开始的时候，你可以使用 4 个机器，每个机器上面建 8 个逻辑数据库；如果 4 个 MySQL 不够用了，那么可以使用 8 个机器，创建 4 个数据库。
这个方案的好处就是，你不需要写数据迁移功能，只需要迁移数据库就可以了，然后代码这边只要修改配置就可以了。这个方案只是做整个数据库的迁移，没有数据的比较，没有临时工具，会方便很多。
如果你们公司不景气了，需要减少机器，那么也很方便，只要把该机器上的数据库迁移到其他机器上就好了，然后修改下我们的代码，改下路由配置就 ok 了。
路由规则：
库：userId 模 32（库数量）；
表数据：(userId / 32) 模 32（表数量）；