（1）回顾：
    分库分表真正难的地方应该在于真实的实践经验，就是大家在学习后，真正能用到自己的业务场景里思考一下，
    看看在自己的业务场景下，如果业务表做成上千万数据的大表，此时各种查询性能如何？完了如何分表，按什么字段分，是否要建立索引映射表，跨库跨表的查询应该怎么做，选用什么数据库 中间件，然后如何进行数据迁移，最后如何进行扩容。这些如果能在自己负责的项目里实践一下，效果是最好的。

    （2）最后一个话题：
    过了几年后，每个表的数据量都增长到一定水准，比如刚拆分的时候每个表才100万数据，结果过了几年，每个表都增长到几百万数据，此时应该怎么办？当让是把表进一步拆分，增加更多的表。 增加完了后还得做数据迁移，更改系统的路由规则，极为的麻烦。
    刚开始我们可以多分一些表，比如数据量是10亿级别，可以分为10000个表，每个表才10万数据，而且后续计算好增量，可能10年，20年过后，单表数据才百万级。那么就不会出现上面的情况了。 所以说一开始表数量宁愿多一些，也别太少，最好计算一下增量，让自己永远不会增加更多的表。
    其次，万一过了几年后，每台服务器上的存储空间要耗尽了呢？或者是写并发压力太大，每个服务器的并发压力都到了瓶颈呢？那就要增加更多的数据库服务器了，但是增加服务器之后，表怎么办？ 此时就得把表均匀分散迁移到新增加的数据库服务器上去了，然后再修改一下系统里的路由规则，用新的路由规则保证正确的把数据路由到指定表以及指定库上去就没问题了。


    （3）总结：
    因为关于数据库扩容这快，虽然网上很有方案，但是还是建议，刚开始拆分时表数量可以多一些，避免后续要增加表。然后数据库服务器要扩容是没问题的，直接把表做一下迁移就行了，然后修改 路由规则。

    知识点：库或者表迁移，可以不停机迁移到新的服务器，使用不停机双写的方式
    知识点：分库分表最好提前预估容量，也可以后期单表迁移到分库分表，分库分表扩容相对来说比较麻烦。
    知识点：分库分表与tidb如何选型呢？ 最好还是直接使用 tidb
    知识点：旧的项目还是维持现有的分库分表，新的项目选型可以考虑tidb，或者说结合自己的业务是否有分库分表后分页，多分片等问题的查询。
    知识点：
    扩容的话，如果不动数据库实例，迁移表的方案，看了shardingjdbc的路由，如果对urserid进行分库，orderid进行分表，同一个userid的订单再同一个库，订单是分散的，如果要改表 的路由，这个方案也要对同一个库中的所有的订单数据做一次迁移。