面试题
如何设计可以动态扩容缩容的分表分库方案？
面试官心理分析
对于分表分库来说，主要是面对以下问题：
- 选择一个数据库中间件，调研、学习、测试
- 设计一个分表分库的方案，需要分成多少个库，每个库分成多少个表，比如3个库，每个库3个表
- 基于选择好的数据库中间件，以及在测试环境建立好的分表分库环境，然后测试以下能否正常进行分表分库的读写
- 完成从单表单库到分表分库的迁移，双写方案
- 线上系统开始基于分表分库堆外提供服务
- 扩容了，扩容成6个库，每个库12张表，该如何增加更多的库和表呢？
这个就是必须要面对的事情，就是当你把分表分库方案弄好了之后，然后一堆库和一堆表都建好了，基于分表分库的代码已经开发完成了。数据已经分布到各个库和各个表里面去了，而且你还通过双写方案上了以下系统，已经直接基于分库分表的方案在搞了。
那么现在问题来了，你如果目前分的这些库和这些表又无法支撑了，需要继续扩容了怎么办？这个可能就是说你的库容量又快满了，或者是你的表数据量又太大了，也可能是你每个库并发太高了，又得继续扩容。
面试题剖析
停机扩容（不推荐）
这个方案就跟停机迁移一样，步骤几乎一致，唯一得缺点就是那个导数据的工具，是把现有库表中的数据抽取出来慢慢导入到新的库和表里面去。但是最好不要这么做，因为既然选择分表分库就说明数据量实在是太大了，可能多达几亿条，甚至是几十亿，你这么做，可能会出问题。
从单库单表迁移到分库分表的时候，数据量并不是很大，单表最大也就几千万。那么写个工具做迁移还可以，1小时左右数据就可以跑完。
如果3个库+12个表，跑了一段时间，数据量就1-2亿。光是导2亿的数据，就要耗费几个小时，6点刚刚导完数据，还要搞后续的修改配置，重启系统，测试验证，10点菜可以搞完。所以不能这么搞。
优化后的方案
一开始上来就是32个库，每个库32个表，那么总共就1024张表。
按照这个做法，基本上国内的互联网公司是够用了，第二，无论是并发支撑还是数据支撑都没问题。
每个库正常承载的写入并发量是1000，那么32个库就可以承载32 * 1000 = 32000的写并发，如果每个库承载1500的写并发，那么32 * 1500 = 48000的写并发，接近5万的每秒写入并发，前面再加上一个MQ，削峰，每秒写入MQ8万条数据，每秒消费5万条数据。
有些除非是国内排名非常靠前的这些公司，他们的最核心的系统的数据库，可能会出现几百台数据库这样的规模。
谈到分库扩容，第一次分库，就一次性给够。
刚开始的时候，这个库可能就是一个逻辑库，建在一个数据库上，就是一个MySQL服务器可能建了N个库，比如32个库。后面如果要拆分，就是不断在库和MySQL服务器之间做迁移就可以了。然后系统配合着改以下配置即可。
