前提:

1.原有库是mysql数据库,已经根据用户pin分片
2.每片是一主两从
3.主表已经分过表了
4.数据库所在服务器为4C8G
5.库中数据量已经超过千万,而且以每天3万多的数据持续增长,将来每天或许会更多
6.库内数据为订单数据，每时每刻都有新的订单产生，每个订单都要经历多个状态的变化，最终变成完成状态，每次变化状态，都会对数据库进行修改

正题：

现在这样的数据库，其实是完全可以支持现有业务，但考虑到以后随着数据量的日益增长，每次查询都要在千万数据中查找，但其实大部分查询，都是查最近的数据，历史数据几乎不查询，基于这个条件，就考虑到可以做个分库，也就是冷热分离。

所谓冷热分离，网上有很多说法，而我之所以做冷热分离，最终目的，就是为了将经常使用查询的数据放在生产库中，而查询不多的历史数据就放在历史库中，这样既可以保证数据的完整，也可以减轻生产库的压力。

既然有这样的分库查询，那就涉及到两个库的数据同步（这里叫生产库和历史库）
生产库放的是热数据，历史课放冷数据

正常下单后，订单数据还是添加到生产库中，但是每次数据在生产库的变化，都会多发一个mq出去,mq中带有这个订单数据的唯一主键和订单所改变的状态

历史库接收到这个mq,再反查生产库，获得这条数据，然后在历史库做相应的状态更改，这样就可以保证历史库和生产库的数据统一

如下图：

---

对于生产库，原则上只保留500万左右的热数据，其余历史数据，全部放在历史库，这样又会有两个重点：数据迁移和多数据源的查询

1.数据迁移

以下提供几种数据迁移的思路
1.1.执行一个job,定时每天凌晨开始自动迁移，每次迁移若干条，这样就会在不知不觉中将数据迁移完，这样最保险，但不是效率最高
1.2.直接用一个线程池，最多开五个线程（具体能开几个，看自己的机器性能），然后每个线程每次只跑一天的量，这样其实也是很快的

2.多数据源的查询

有了两个数据源，那么什么时候查生产库，什么时候查历史库就是需要考虑的一个问题，我这边完全是业务方面的区分，这里只提一嘴，供参考
2.1.针对单条数据的查询，单条数据的查询一般发生在刚刚下单后，所以优先查询生产库，生产库没有，再去查询历史库。
2.2.针对某一时间段内，多条数据查询list,这里我们可以预先定义一个分割线，这个分割线是一个日期，这个日期就是生产库最早一条数据的日期，有了这个分割线，那我们只需要拿要查询的日期区间和这个分割线做比较，即可确定
2.3.针对多个分散订单的查询list,理论上没有任何规律，但是由于历史数据发现，这种情况一般有数量不多，数据多在近期的特征，所以还是优先查询生产库，查不到再查询历史库

思考

这个冷热分离的好处，就是将不常用的数据放在历史库中，当然，这个历史库也可以是多个，也就是一个生产库，多个历史库，每个历史库都存放某一时间段的数据

扩展

作为思考，如果以后每天的数据量都很大，我将考虑在数据库之前加一层缓存，比如用redis等非关系型数据库,或者用es，因为以前也尝试过用这样的方式来缓解数据库的压力，但发现会存在低几率的数据丢失，所以在这些又会涉及到数据的准确性，数据的即时同步将会是一个很大的挑战，但这应该是现有技术中，对于上亿级别的数据即使查询，比较好的方式了