MySQL 数据冷热分离
历史数据归档的挑战
大部分业务数据的读写特征，都是最新产生的数据会被更频繁地读取或更新，而更久之前的数据（如1年前的聊天记录或订单信息）很少被访问。
随着业务发展，数据库系统中会积累大量访问频率很低甚至为0的数据，这些数据的积累容易导致如下问题：
针对如上问题，一种做法是对历史数据做归档，将长期不使用的数据迁移至以文件形式存储的廉价存储设备上，如阿里云OSS或者阿里云数据库DBS服务。
然而，在实际业务中，历史数据并不完全是静态的，针对几个月甚至几年前的历史数据，依旧可能存在实时地、低频地查询甚至更新需求。例如，在阿里巴巴内部，对淘宝或天猫历史订单的查询、对企业级办公软件钉钉历史聊天记录的查询或对菜鸟海量历史物流订单的查询等。
历史数据归档的诉求
- 为了解决历史数据的读取和更新问题，可以使用一个单独的数据库用来存储归档的数据，即历史库。业务对单独的历史库一般有如下诉求：
- 具备
大容量存储空间，支持业务持续将线上数据保存到历史库中，而无需担心容量问题。 - 与在线数据库系统使用
相同的访问接口，如都支持MySQL协议等，确保应用程序端无需修改任何代码即可同时访问在线库和历史库。 成本低廉，如支持通过压缩减少数据所占磁盘空间、使用廉价存储介质等，确保可以使用较小的代价保存海量的数据。- 具备一定的读写能力，能够满足
低频读写的需求。
MySQL作为世界上使用最广泛的开源数据库系统，一直缺乏一个既能满足大容量低成本要求，又具备一定读写能力的历史数据归档存储方案。虽然业界曾经推出过一些高压缩引擎，如TokuDB、MyRocks等，但受限于单物理机磁盘容量限制，存储的数据量有限。
方案一
数据存储按日期分库分表 + 数据迁移
1、数据按日期存储
2、数据需要考虑状态。有可能有些数据在超过固定时间后还没有到达终止状态。还有可能会有后续动作 -- 业务上规避：将时间跨度较长的业务数据单独存储（业务的时间跨度不能超过数据冷却时间）
3、数据迁移到冷库的方式：逻辑迁移 / 物理迁移
4、数据读取，可能涉及到同时读取热库数据和冷库数据
5、数据迁移过程中的读写问题。
数据迁移过程中，读取数据。先通过业务逻辑推算记录是否存在。如果记录存在，则先尝试读取热库，热裤失败则转向冷库。 （仅针对数据迁移的时间方差内的记录）
数据迁移导致的I/O问题和网络带宽占用问题： 控制迁移的速率？？
6、异常情况
迁移失败
- 数据写入
- 数据读取
方案二
订阅binlog