flashback cluster 会在 tikv 的每个 region 上执行，把旧的数据读上来，然后重新用新的时间戳写下去。所以数据量越大，执行的时间就越久。统计信息相关的数据也会用被恢复的，但内存里的数据就不能保证了。
3 天前
1 这个问题是 sql 本身写的有问题吧，或者时间计算的不对。你分表之后，如果不能准确的定位到某少数表的话，还是需要每个表都查询加数据整合，只是把时间和逻辑从数据库移到了应用而已
2 这个有啥风险呀？从理论上来讲不应该存在这个问题
3 这个用了新的 ingest 模式加索引能快很多，但对磁盘的空间有要求。而且分表还是那个问题，加索引还是要对每张分的表都做一遍的。
3 个月前
大概率是系统整体慢了，网络、io 之类的都有可能
4 个月前
这不是收集统计信息，这是查询统计信息。慢的话可以看下具体的执行信息，分析下
4 个月前
可以试试在最终要跑的机器上编译，编译前加上 export RUSTFLAGS=“-C target_cpu=native”，但不确定 tikv 静态依赖的库里面有没有用到这些指令
4 个月前
是的，对外只有一个 sql 的接口，可以把 tidb 看成一个整体，内部的组件有 tidb-server、tikv-server 和 pd-server。
注意不要在同一个 tikv-server 的集群里混用 txn kv 和 raw kv，会有一些潜在的问题
6 个月前
tikv 就是单纯的 kv 存储，tidb 的话再上面包了一层 sql 的实现。
如果你想用的方便易用角度来看的话，肯定是 sql 比较方便，能支持的接口和功能更丰富。
kv 的好处就是简单，然后裸 kv 的性能也会更好。
6 个月前
没有更多内容了