正式环境下的历史数据迁移方案，你知道几个？

一、历史数据库

MySQL 数据库可以很好地支撑海量的 OLTP（Online Transaction Processing）的系统，但是对于海量的互联网业务来说，数据量是非常巨大的。

假设一天 10 亿笔交易，每笔交易至少需要有一条记录，用于记录该笔交易，这就是通常所谓的流水数据。再假设一笔流水占用 1K 存储空间，那么每日流水占用存储空间 1000G，365 天就需要占用 365T 的存储空间。

即便我们做了分布式数据库架构，有 1000 个分片，每个分片 1 年的流水数据就需要 365G，这还不包括其他数据，仅仅只是一笔交易的流水。而线上的库表和业务就更为复杂了。

或许大家会问：为什么要存储 1 年以上的数据呢？超过一定期限删除不就可以了吗？大家想一想，我们的历史微博是不是都是能看的？我们的淘宝历史交易也都是能查询的？对于金融业务来说，每笔历史交易是不是也都可以可以回溯的？

所以，即便是历史的数据，也要求是可以查询的。所以，对于海量的互联网业务来说，除了线上的数据库，还需要有一套对应的历史数据库，用于查询历史的数据。

注意，我们这里谈论的历史数据库，不是用于数据分析的系统，而仅仅是一个历史查询数据库。

二、历史数据库架构

从架构角度看，线上数据库系统与历史数据库系统的架构如下图所示：