mysql分表和分区的区别浅析？
分区：就是把一张表的数据分成N个区块，在逻辑上看最终只是一张表，但底层是由N个物理区块组成的。这一个是由数据库自动完成的，PARTITION BY来完成。
分表：就是把一张表按一定的规则分解成N个具有独立存储空间的实体表。系统读写时需要根据定义好的规则得到对应的字表明，然后操作它。这一个是表设计的时候，人为处理的。
mysql分区分表哪个好？
MySQL分区和分表都是优化数据库性能的手段，但两者的实现方式和目的不同。
分区主要是将一个大表按照某个规则拆分成多个小表，便于管理和查询；而分表则是将一个大表按照某个规则拆分成多个同构的小表，以减少单张表的数据量，提高查询性能。具体选择哪一种方式，需要根据实际情况和需求来进行权衡和选择。
mysql先分了10张表，后续在分表如何处理？
MySQL分库分表（其他关系型数据库也相似），通常的方案都用主键mod分表的数量，来把数据路由到某一个数据库分片上。例如分了10张表，那么就是ID%10，得到结果0-9，代表不同的表。
但是当数据量进一步增多的时候，单库的数据量达到了一定的级别之后，那么就需要分更多的表，那么这时候有哪些处理方案呢？
做数据迁移
最简单暴力，也是最麻烦的一个方案。
因为当分表（分库）数量增多的时候，因为分片规则的变化，每个表的数据都要被重新分配到多个新的表；这种方法虽然最直接，但是带来的问题也非常大：
数据迁移时间会比较长，需要迁移时间；
如果业务不能停的话（在线迁移），还要解决增量数据和历史数据一致性的问题；
不做数据迁移
那么有没有方法，当数据增长到现有分表极限的时候，加表或者加库的时候，可以避免数据的迁移呢？说白了，我们需要增加分表算法的复杂性，让算法可以兼容增加分表前后的数据路由：
先说一个简单的办法，（为了方便讲述，下面就把id当做分表字段），如果id是一个增长的全局序列，每个表存500万的数据，那么可以id=1-500万存到table_1，id=500万零1-1000万存到table_2，理论上这种方法是可以无限扩容的，但是问题也显而易见，就是每个阶段的数据insert会集中在一个表/库上，虽然能避免数据迁移的问题，但是数据热点的问题没有解决。
- 如果id是一个增长的全局序列，当前有十张表，那么分表的算法为：id%10，根据0-9路由到10个表中；当表扩到20张的时候，扩容那一刻取max_id，那么未来分库的算法也就变成了：
if(id<max_id){id%10} else {id%20};
有些分表的算法本身就带时间戳，可以基于id中的时间戳来实现，比如Twitter-Snowflake算法，这个算法是一个64位的Long值，前42位就是一个精确到毫秒的时间戳，那么我们的分库算法也就可以以某个时间点来判断：
if(id中的时间<增加分表那一刻的时间){id%10} else {id%20};
我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。
欢迎关注我，一个程序员老司机，和你分享编程、运营、需求等等经验和趣事。
根据你的问题描述，其实就是对MySQL数据表进行重新分表，下面我来和你分享一下我的观点，希望能够帮助到你。
首先你已经有了10个表，那么现在分表肯定需要重新组织这10个表的数据，所以我们可以这样做，首先创建好你的新分表，比如50个新的分表，然后用程序依次将这10个表的数据按照新规则插入到新的分表里面，完成之后，将应用程序里面的数据表名称改成新数据表，从而完成整个操作。
但是这里有一个问题，因为我们的数据随时都在增加或者修改、删除，如果在业务繁忙的时候来进行的话，很容易导致数据丢失或者数据不完整的情况，所以，尽可能将这个分表操作放在晚上或者业务不繁忙的时候，甚至关闭整个系统一段时间都可以，如果选择晚上的话，怎么处理好新增的数据和修改的数据呢？可以考虑临时增加几个数据表触发器，然后在分表完成之后，根据这些触发器来进行修改数据的修复。
不过在做项目的时候，我们还是尽可能将这个设计好，因为重新分表的成本非常高。