【TiDB 使用环境】生产环境 /测试/ Poc
【TiDB 版本】7.5.5
【操作系统】centos7
【部署方式】云上部署（什么云）/机器部署（什么机器配置、什么硬盘）
【集群数据量】
【集群节点数】
【问题复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【复制黏贴 ERROR 报错的日志】
【其他附件：截图/日志/监控】
在执行 FLASHBACK CLUSTER 之后，TiDB 中的统计信息可能不再准确。这是因为 FLASHBACK CLUSTER 操作会将整个集群恢复到指定的时间点或 TSO（事务序列号），这可能导致数据的状态与当前统计信息不一致。因此，为了确保查询优化器的有效性，建议在执行 FLASHBACK CLUSTER 之后重新收集统计信息。这可以通过执行 ANALYZE TABLE 命令来实现，以更新表的统计信息，从而帮助优化器选择更高效的查询执行计划
1 个赞
谢谢表妹大佬。
另外我看flashback database 和 flashback table 执行都很快，因为他们仅仅是将gc worker 任务从元信息表中删除，所以执行database和table的flashback 应该不会影响统计信息吧？
但是我看FLASHBACK CLUSTER就没那么快了，下面是我的FLASHBACK CLUSTER测试过程：
- 使用sysbench创建一张表test1并压入100000000行数据
- 记录时间戳 tempstamp1
- drop 这张表
- 再次使用sysbench创建一张同库同名表test1并再次压入100000000行数据
- 执行flashback cluster to TIMESTAMP {tempstamp1};
- 执行时间竟然达到了Query OK, 0 rows affected (16 min 52.18 sec) 之久
请问flashback cluster 的执行时间跟什么有关呢
数据版本回放，需要按照时间有序回放，
简单理解：
- 回溯数据版本
- 确认数据范围
- truncate Table 清空数据
- 回填数据
回填会比较慢了…
个人理解，仅供参考
1 个赞
我按照上面步骤，第4步改成压入10000000（原来的十分之一）， 执行时间缩短为了3min左右；同样如果第四步只压入一条数据，执行时间就为毫秒级别了。那如果是truncate table的方式，这些时间应该一样把，但是实际执行实际看起来跟我后面执行的DML数量有关。
flashback cluster 会在 tikv 的每个 region 上执行，把旧的数据读上来，然后重新用新的时间戳写下去。所以数据量越大，执行的时间就越久。统计信息相关的数据也会用被恢复的，但内存里的数据就不能保证了。
1 个赞
你说的数据量指的是原本的一亿行数据，还是flashback 时间点之后的增量数据？我测试下来是跟增量数据有关，增量越多，闪回越慢，反之越快。
要返回的时间点和最新的时间点之间的数据变化量，增删改有影响，但一个 key 修改多回也只算一次影响
1 个赞
明白了 
那flashback table 和 flashback database 之后的统计信息准确吗？是否还需要重新收集？
理论上相对准确。最好还是手动收集一遍。
因为统计信息表中的列带 table id，如果上下游表 id 变了，就得重写所有 value 了。 不过 flashback 这个操作看起来并不会重写 table id。理论上看起来没问题。
1 个赞
好的。
此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。