作者回复: 看来成长比较迅速呀。这个开源中间件比较新，去年刚开源的时候了解下源码，顺便实践了基本功能。

作者回复: 我们的分表一般是根据[字段的hash值%表数量]或来进行分配的。

假设某分表字段的哈希值4、8、12，原来的表数量为4，所以这几个数据都会在一个表中。当扩容到8时，只有12会迁移到第五张表中。

如果扩容到6张表的话，此时哈希值为4的数据会迁移到第五张表，哈希值为8的需要迁移到第三张表，只有哈希值为12的不需要迁移。

作者回复: 可以的，TiDB是一种集中式的数据存放解决方案，可以节省开发人员很多工作量。

作者回复: MySQL的表分区存在一些限制，常见的有：分区字段不能为NULL，避免建立和分区列不匹配的索引。

除此之外，底层实现的表分区，对MySQL来说其实是一个性能消耗的过程，特别是范围分区，服务器需要扫描所有的分区定义的列表来确定具体的分区。

表分区在操作数据过滤之前，是需要打开并锁住所有底层表的，这个过程是在分区过滤之前发生的，所有是一个非常消耗性能的过程。

分区表的维护成本也是很高的，特别是重组分区。

总之，MySQL的表分区实现偏底层，定制不灵活且性能不是很好，维护成本高。所以很多DBA不建议使用。

作者回复: sharding-jdbc\mycat在行业内使用比较多，各有优势

作者回复: 一般我们都是采用hash求余的方法来实现分库分表，如果在生产环境中出现数据倾斜比较严重，我们需要考虑使用一致性hash算法实现分库分表，也是二次分表的一种实现，只不过可以对局部倾斜数据进行二次分表，实现起来方便，且只影响部分表数据。

作者回复: 前期没有做好分表的准备，后面做表升级工作量就大很多，而风险更高。

例如一个表如果是自增主键ID，而主键ID又跟其他业务表做了耦合，当我们要做表升级时，需要用另外一个字段做分表字段，这时候就存在主键ID在分表后可能存在冲突的问题。 所以一开始我们就要想到这张表有可能需要做表升级，在做表关联时用另外一个非自增主键ID做关联，或者使用全局自增ID或雪花算法统一获取全局主键ID。

阿里云的数据库暂时没有用过，多了解支持的一些功能，匹配下是否更适合自己的业务。

作者回复: 可以自我实现一个snowflake工具类，理解雪花算法的原理即可

作者回复: 理论上来说，不跨表垮库查询，是没有数量上限，因为路由是不会存在数量越多性能越慢的情况。

作者回复: mycat是一个中间代理层，存在中间相互通信的性能损耗，其他方面挺好的。

作者回复: 正如文中提到的，可以通过数据库或缓存来实现严格的递增，但会有一定的性能消耗。鱼和熊掌两者不可兼得，目前雪花算法是一种折中解决方案。