背景
请求量比较低系统只是历史数据比较多的数据可以不考虑分库分表，做数据归档方案即可 或者分库分表里的时间比较久的数据移动到归档库中可以避免扩容
归档库的选型
可以考虑OceanBase
OceanBase具有数据强一致、高可用、高性能、在线扩展、高度兼容SQL标准和主流关系型数据库、低成本等特点。OceanBase至今已成功应用于支付宝全部核心业务：交易、支付、会员、账务等系统以及阿里巴巴淘宝（天猫）收藏夹、P4P广告报表等业务。
TokuDB
TokuDB 是一个高性能、支持事务处理的 MySQL 和 MariaDB 的存储引擎
归档策略
归档可以设定一定时间内可以读，过一定时间后也完全归档（就是不能读，可以申请恢复后读）
归档注意点
- 归档程序注意线程数控制，读取线上mysql需要在低峰期
- 归档程序删除的数据不会主动释放，需要进行mysql释放磁盘空间操作
- 如果历史久远的数据被归档了，业务处理找不到怎么办。比如说免密支付一直没支付，过了一年后才支付。
-
- 第一个解决办法，双重查询。如果生产数据库找不到业务数据，那就去归档库查找。这个解决办法适合离线的业务。
-
- 第二个解决办法，设计一个兼容方案，提供数据逆向接口，反向将归档数据库的记录重新还原到生产库。那这种解决办法，只适合少量因为归档数据造成业务异常的业务场景。
- 归档后查询响应RT会高
