tidb先内部数据更新/删除时有记录数据更新时的时间戳，而且提供了tikv_gc_life_time来设置可回溯的数据最早时间；
我们的使用场景是在用户的点击点赞等等行为序列的记录上:比如每点击一次就触发replace into操作，更新点击序列，相应保存更新前的数据，加一个时间戳作为版本号；
现在遇到的问题就是如果有的用户一分钟内点击了十多次，或者一天累积点击上千次(先tikv_gc_life_time设置为24小时)，相应就会产生很多时间比较近的时间戳版本；
想到的一种解决方案是：版本的多种粒度支持，数据维度变化较快的(比如1分钟内update了十多次)支持每隔多久记录一个变化的时间戳，比如10分钟内有多个时间戳的话保留最近的一个时间戳版本即可，其余删去，以加速rockdb的seek操作；对应维度变化比较慢的(比如1天才被update一次)，仍然使用tikv_gc_life_time控制最久保存时间；
你好。现在的 GC 机制是可以恢复到 tikv_gc_safe_point 内的任意一个时间点。上面提到的方案是无法保证全局的数据一致性的。另外有更多的需求可以在 5.0 的需求贴进行反馈。
您好，我们这边的需求更像是hbase提供的3个timestamp version概念；并不会利用gc做恢复；更多的是查某个时间点之前的数据；
我这边整理下需求提交在5.0需求中吧
好的，您也可以在github提交issue，多谢。