mysql水平分库分表后老数据怎么处理

数据库存放数据太多，需要水平分库分表，但是水平分库分表后老数据怎么处理，希望给出解答

这其实是一个没有最优解的问题。如果历史数据需要长期保留，那么可以根据数据量的大小，按天或按月或按年来对历史数据进行纵向分表，也可以按某一个或多个字段（例如部门、国家、品种等）进行横向分表。分表后的主要问题就是查询时的处理，如果对历史数据进行查询，要么限制查询条件，例如横向分表，就要求每次只能查询一个门类的数据；要么就采用Union的方式来查询。
另外，分表必须根据实际业务情况，看看查询请求有没有特点，例如80%的查询都是针对近一年的数据，那么就可以考虑把一年前的数据放入历史库中。

可以存入历史表中，或者将其汇总的结果写入单独的表。

• 这个问题的回答你可以参考下: https://ask.csdn.net/questions/749352
• 你也可以参考下这篇文章：mysql 垂直分表和水平分表
• 除此之外, 这篇博客: MYSQL实现水平分表中的 为什么要分库分表？ 部分也许能够解决你的问题, 你可以仔细阅读以下内容或跳转源博客中阅读:
  

• 提升性能、增加可用性。
  1. 从性能上看

  • 随着单库中的数据量越来越大、数据库的查询QPS越来越高，相应的，对数据库的读写所需要的时间也越来越多。数据库的读写性能可能会成为业务发展的瓶颈。对应的，就需要做数据库性能方面的优化。本文中我们只讨论数据库层面的优化，不讨论缓存等应用层优化的手段。
  • 如果数据库的查询QPS过高，就需要考虑拆库，通过分库来分担单个数据库的连接压力。比如，如果查询QPS为3500，假设单库可以支撑1000个连接数的话，那么就可以考虑拆分成4个库，来分散查询连接压力。
  • 如果单表数据量过大，当数据量超过一定量级后，无论是对于数据查询还是数据更新，在经过索引优化等纯数据库层面的传统优化手段之后，还是可能存在性能问题。这是量变产生了质变，这时候就需要去换个思路来解决问题，比如：从数据生产源头、数据处理源头来解决问题，既然数据量很大，那我们就来个分而治之，化整为零。这就产生了分表，把数据按照一定的规则拆分成多张表，来解决单表环境下无法解决的存取性能问题。

  2. 从可用性上看

  • 单个数据库如果发生意外，很可能会丢失所有数据。尤其是云时代，很多数据库都跑在虚拟机上，如果虚拟机/宿主机发生意外，则可能造成无法挽回的损失。因此，除了传统的
    Master-Slave、Master-Master 等部署层面解决可靠性问题外，我们也可以考虑从数据拆分层面解决此问题。

  分库分表实现方案：
  

• 您还可以看一下 李连宇老师的Mysql调优课程中的 分库分表小节, 巩固相关知识点