@Daniel Cai，怎样实现分片？这个概念第一次听说，抱歉啦，能否提供点资料学习下？十分感谢啦

@Daniel Cai，你说的分片 是分布式部署和分布式查询吗？

@HNLY: 这个网上比较多，找下shard，分片就可以巴拉出来不少。

简单点说就是当机器集群性能到瓶颈后已经不能再通过堆硬件的方式再提升的时候只能做硬件降级，把数据分拆到不同的机器上，每台机器上只保留一部分的数据，通过这种方式可以很容易顶住海量的数据及压力。

虽然这样做得到了极大的性能及扩展性，但牺牲了数据查询的一些便利性。

举一个简单的场景

你有海量的用户数据，有功能需求需要根据用户id去查用户信息，的确可以通过集群，硬件，良好的索引来达到性能需求，但这个总会有天花板的，那么一旦到了那个时刻就没招了（不考虑缓存等）。

那么在相同场景下，如果这些用户信息根据一定规则分布在若干台机器上，那么不需要多牛逼的硬件也可以达到相同的性能，而且如果分布规则较好的话（一致性hash）甚至可以在碰到性能瓶颈时通过横向加硬件的方式继续提升，这个性能理论上是没有上限的（能达到几万来条数据低压力场景下查相同的性能）。

上述硬件降级横向扩展的方式就是分片，上述场景中可以很容易的通过一个hash后定位到一个唯一的用户数据存放的地方，所以针对上述业务的curd是没什么问题的。

但好处不能让你全占了，当功能点再多点，比如就简单的来个用户查询（带个分页），之前的单库方式可以很容易实现，但在分片后就变得极为别扭甚至无法实现，所以针对这种弊端只能在其他方面做妥协。

回到你的问题上，其实冷热数据不需要通过分区来实现，虽然我不是dba，但一般做法就是将老数据（按时间）移到其他表上，再看业务能否妥协（比如只能查近期数据而非全量数据或者通过展示上的限制规避从不同数据源中读数据的问题，一般银行，第三方流水数据量很大的时候都会限制你查一定时间内的数据，有些虽然可以查更老的数据但是会在界面上限制你不可能在一个查询中撸到冷热两种数据）

@HNLY: 你说的分片 是分布式部署和分布式查询吗？

最简单点说，之前可能你查询的都是一个db（不管是单机还是集群都可以宏观看为是一个）。分片后你面对的是若干个db，这样压力就散开了。

ps下：前面忘了说一点，关于一致性hash后扩容的问题，这个网上什么在线扩容那些看看就可以了，实际操作远比那复杂，对开发能力，运维能力考验相当大（有些场景下根本不可能实现）

@Daniel Cai: 非常非常感谢您耐心细致的解答。
另外，不知能否问下常规的冷热备份的方法（将老数据（按时间）移到其他表上）如何处理的？
例如，交易记录表中记录着2000年到2017年的数据，我如何将2000-2015年的老数据动态备份到 其他表？我想到的是用“select into” 效率会更高些，不知是否还有更好的办法。但是，原来表的2000-2015的数据怎么办？直接使用delete 或许速度也不快呀。

@Daniel Cai: 不会是先将2016-2017的数据存入临时表，truncate 原表后再插入吧，这个insert...select速度也不快呀。难道是 “truncate->delete->select into from 临时表”？这个风险有点大吧

@HNLY: 不太清楚dba针对这种场景会怎么操作，如果有master 多slave这种模式下可能直接从slave上读了插入后再delete原表数据，truncate这种由于没有日志当然速度快但正式环境上不能这样用。效率什么的这个应该可以忽略，这个没必要快，甚至一次挪一部分类似分页的样子一点点的挪完不丢数据就可以了。