简介
当你的 MySQL 数据库上业务跑了一段时间之后，就会有一些冷数据了，有些冷数据业务根本不会去查询，那么这些冷数据就需要从交易库归档到历史库。
这样做主要有两方面原因：
节约成本，因为交易库的服务器硬件会比历史库价格昂贵的多；
提高数据库查询速度。
本文将通过三个部分，来介绍如何将冷数据归档：
MySQL 数据库冷数据有哪些归档方案
MySQL 数据库冷数据归档方案如何选择
如何丝滑的从正在使用的单表中归档部分冷数据，并从单表中删除归档数据
归档数据场景
生产 MySQL 数据库运行一段时间之后，总会有一些数据，应用不需要了，但是数据也不能直接删除，所以需要数据库维护人员，将这些历史数据进行归档。
在这里总结了一下，被归档的表总共有 3 种场景。
按照天、月、年分表归档场景
举个例子，业务订单表按照月份进行分表，在数据库里，表会创建成以下形式：
t_order_202001
t_order_202002
....
t_order_202011
t_order_202012
如果产品设计，只需要查询最近 13 个月的订单数据，那么 13 个月之前的表就属于冷数据，可以做归档处理，此类场景，数据归档比较容易，如果是成熟的产品，这种场景会很多。
分区表归档场景
有些时候，业务量不高不低，所以将表设计成分区表，按照月、年进行分区。如果产品设计，只需要保留最近 13 月的数据，那 13 个月之前的数据，就需要做归档处理。
这种场景需要按照日期查询条件，将归档数据导出，并导入到历史库，最后将归档分区删除掉。
单表部分数据归档场景
单表部分数据归档场景，这个场景对于数据库运维人员来说，是最麻烦的。
在业务初期，由于设计人员没有正确估计数据量，后期业务业务起量，导致单表数据太多，影响应用 SQL 语句的执行效率，导致查询性能下降，不得不将冷数据进行归档，归档的时候，不能影响业务，所以只能将归档数据导出，让后一条条的将归档的数据删除，还不能删除的过快，否则还会造成主从复制延迟，影响业务查询。
MySQL 数据库冷数据有哪些归档方案
MySQL 数据库冷数据归档方法还是挺多的，在这里给大家介绍 4 种归档方案，每个方案都有的适用场景。下面就一起来看看吧。
