为什么要做冷热分离
单日访问统计表，也就是 t_stats_today 表，没必要做分表，因为这个场景是用户想查询某一天该数据的访问记录或者该分组下所有数据的访问记录，这个实际上用到的可能性很小（因为我们默认的查询区间是最近一个星期的访问记录，对于之前的某一天的访问记录，一般用不到）。
那我们可以做个优化，也就是冷热数据分离，把最近一段时间的单日访问记录存到数据表中，但是更早的数据可以通过备份表（用一个 back 标识为单日访问记录的备份表）存储到适合大容量存储的数据库但是查询效率相比于热库较低，比如 Postgresql 等。如果用户真要访问这种冷门的数据再从冷库中查询。
同时也是为了适应取消 gid 之后，减少查询当日访问统计记录的关联查询次数。那这样我们那个绑定表导致的笛卡尔积问题就不用考虑了。4 项目问题–分库分表相同分片键使用left join会出现笛卡尔积
其他问题
怎么实施冷热数据分离
实习的时候就有这种场景，把大量的推荐以及推送日志冷热分离，减少对线上数据库的存储压力。（具体还在研究如何实现）
- #task 如何实施冷热分离？ 🔽
应该要结合项目考虑。
冷热分离有什么问题
- 首先你的代码复杂度会提高很多，你划分冷热数据，在比较复杂的场景下很难实行。如果划分不够好，导致频繁的访问冷库数据，性能会降低很多。
- 还有问题就是冷热数据的同步，以及数据一致性问题，你打算什么时候进行热库同步数据到冷库呢。
- 高可用性，对于不同的数据库，你维护的方式也不同，不管是冷库还是热库挂掉或者性能下降都会导致系统问题。
… 大概想到这么点，可能会再补充吧。
怎么定义冷数据和热数据的
冷数据一般就是线上环境中对于一些实时性要求较低的功能，比如支付，你不可能交给冷库来做，因为性能不够高，而且它的数据是由热库按照一定规则同步过来的，可能会有一些延迟。
热数据相反，就是对于实时性以及计算要求高的需求，需要用热库快速查询和返回数据，并且保证数据的准确性。
ps：
只是一个简单的想法，并不是一个系统性的文章，请见谅，待之后真正做了之后会考虑发布
