gc时间设置相对长一些也没有太大的影响，不过要看查询类型，
我这里是24h没有太大影响，但有些情况下触发bug可能会导致查询的时候有过多的mvcc的版本，所以改的时候要有足够的测试和观察，如果不对尽快改回去
输出binlog文件的前提是你配置了file形式的drainer，看你上面的描述大概率是没有，所以现在只能br恢复然后捞数据
是的，增量还是得用binlog，除非你误删的数据就在br备份的数据里面
感觉增量恢复，你有增量备份吗？BR 只能是全量恢复吧？全量备份到删除之前这段时间内删除的数据有变化吗？
由楼主的问题我想到一个相关的问题，tidb能不能像oracle的dg配特定的延时同步备库呀？
tidb的gc时间设置很可能不能满足发现误操作的时间点要求，就如同oracle的undo表空间及undo_retention也不能很很大，这就导致flashback功能经常因发现误操作的时效性不够而不能用。
这种情况下oracle除了提供最笨重的利用物理备份+归档日志来临时异机恢复一个测试库来找回指定误操作时间点前的数据，还提供了另外几种应对方式:
0.flashback table或flashback query找历史数据:由于发现误操作的时间过久，超出了undo的大小和undo_retention支撑的范围，flashback找历史数据的方法已不可用;
1.logminer分析归档日志，找出误操作时的具体的sql和数据; (对应mysql/tidb的解析binlog日志找历史数据的广式)
2.保证还原点:突破undo+undo_retention的限制,但需要很大的fra空间支撑以便保留足够多的闪回日志[库级行为，生产主库应该不允许为找几条数据大动干哥而将库整体倒回到过去太久的某个误操作时间点，应通过主备同步传导的广式在备库上进行该方法的应用。通常此法最适合测试环境];(不知道tidb支不支持保证还原点功能？)
3.dg特别设定的延时同步备库_应对超出flashback范围的误操作。(不知道tidb支不支持延时备库功能?)
tidb有没有可以用于生成回滚语句的工具？类似myflash那种，要不恢复一点数据非得从头开始？
只要数据没有GC，有很多办法能恢复数据的，比如直接查询历史数据，然后把要恢复的数据单独拿出来进行恢复。其他方案楼上很多大佬回复了。
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。