照你的需求来看，可以有两种方式，一种是分表，另一种是分区 首先是分表，就像你自己所说的，可以按月分表，可以按用户ID分表等等，至于采用哪种方式分表，要看你的业务逻辑了，分表不好的地方就是查询有时候需要跨多个表。 然后是分区，分区可以将表分离在若干不同的表空间上，用分而治之的方法来支撑无限膨胀的大表，给大表在物理一级的可管理性。将大表分割成较小的分区可以改善表的维护、备份、恢复、事务及查询性能。分区的好处是分区的优点： 1 增强可用性：如果表的一个分区由于系统故障而不能使用，表的其余好的分区仍然可以使用； 2 减少关闭时间：如果系统故障只影响表的一部分分区，那么只有这部分分区需要修复，故能比整个大表修复花的时间更少； 3 维护轻松：如果需要重建表，独立管理每个分区比管理单个大表要轻松得多； 4 均衡I/O:可以把表的不同分区分配到不同的磁盘来平衡I/O改善性能； 5 改善性能：对大表的查询、增加、修改等操作可以分解到表的不同分区来并行执行，可使运行速度更快； 6 分区对用户透明，最终用户感觉不到分区的存在。
mysql解决大数据量存储问题的方法是分表。
1.如何去分表
根据什么策略把现有表中的数据分到多个表中，并且还有考虑到以后的扩展性上。
建立一张索引表，用户id与数据库id对应，（这里他将相同结构的表分在了不同的数据库中进一步减少压力，但同时对于数据的同步也需要通过其他手段来解决），其本质也是分表了同时分库了。这么做的好处是便于以后的扩展，但损耗一点性能，因为会多一次查询。这样索引表可能会成为新的瓶颈，除非用户不会一直增长哈。
我的做法属于另一种，写了个算法通过计算某列值，按照一定规律将数据大致均分在每个分表中。至于扩展性，写算法时候考虑进去了以后增加分表数的问题了。
选择哪种策略，是要看自己的表的业务特点了，方法没有绝对的优缺，还是要根据自己的需求选取。
2.分表之后主键的维护
分表之前，主键就是自动递增的bigint型。所以主键的格式已经提早被确定了，像什么uuid之类的就被直接pass掉了。
还有想过自己写一个主键生成程序，利用Java 的Atomic原子量特性，但是考虑还需要增加工作量并且高并发下，这里很可能是个隐患。
还有就是通过应用层上管理主键，如redis中有原子性的递增。
内容全部来源于网络收集，如有侵权，请联系网站删除：QQ：24596024