同样的sql，但分到这个tikv上执行的多。有可能是读取热点。 如果是要读取的数据都集中在这个tikv上，造成的负载不均衡。 参考 https://docs.pingcap.com/zh/tidb/stable/troubleshoot-hot-spot-issues 看看能否解决。

之前看你提过这个mvcc版本太多，不触发gc的问题。现在解决了吗？会是这个原因吗？

空region相关的问题，你可以看看这个帖子。

topsql https://docs.pingcap.com/zh/tidb/stable/top-sql 这个界面对付单台tidb负载不均衡的情况是比较有效果的。可以尝试使用。

不能复现的bug，那就只能随缘了。下次出的时候尝试一下是否有机会。

最好是能尝试一下tiflash+mpp。 根算子是hashagg的情况下，提升会很明显。

insert平均最高的也只有20ms。 优化到多少是你能接受的？

这是由于2以上版本要首先初始化源数据库可以使用如下命令初始化 ./hive/bin/schematool -dbType mysql -initSchema 会是这个原因嘛？

很好的实践 强制checkpoint操作没有。 https://docs.pingcap.com/zh/tidb/stable/br-pitr-manual#查看备份数据元信息 但是可以通过br log metadata命令，确保最近的可恢复时间点，包含之前完整的一天。不过想要精准控制按秒级划分的话，可能确实有点难。

这个执行从超长的sql的执行计划有嘛？ 这是个bug的话，现在也挺难复现的。 如果方便可以考虑保存一下执行现场的信息。 https://docs.pingcap.com/zh/tidb/stable/sql-plan-replayer 可能有助于定位这个问题。

有点彪悍啊。

ok，是我没注意审题。 我仔细想了想，tiflash的话好像还真没有想到特别好的办法。看看其他大佬怎么说。

https://docs.pingcap.com/zh/tidb/stable/titan-overview 你可能需要尝试一下titan。我个人是没有使用过。不过看描述就是因为应对vale比较大的场景的。 Titan 是基于 RocksDB 的高性能单机 key-value 存储引擎插件。 当 value 较大（1 KB 以上或 512 B 以上）的时候，Titan 在写、更新和点读等场景下性能都优于 RocksDB。但与此同时，Titan 会占用更多硬盘空间和部分舍弃范围查询。随着 SSD 价格的降低，Titan 的优势会更加突出，让用户更容易做出选择。

看看这个pd是不是leader，不是leader可以直接重启这个pd。如果是leader，把leader转出去也可以重启的。 https://docs.pingcap.com/zh/tidb/stable/pd-control#member-delete--leader_priority--leader-show--resign--transfer-member_name

这个不实际操作一下，很难回答。我个人感觉这样恢复很难，非常不靠谱。看看是否有其他大佬有好的实践。

还有就是关注这个图里面明显亮斜线的部分是否是索引。局部的亮斜线看上去比较多。 https://docs.pingcap.com/zh/tidb/stable/dashboard-key-visualizer#明亮斜线需要关注业务模式 如果是索引写热点，现在确实没啥好办法。 如果不是索引而是表，那这个亮斜线对应的表是非常明确的写热点。需要你用SHARD_ROW_ID_BITS改造一下的。就像你对tblRealtimeSidAIGCDetail这个表做的那样。

https://docs.pingcap.com/zh/tidb/stable/grafana-tikv-dashboard grafana里面找Compaction pending bytes 重点关注这个值掉下去的时候，也就是发生compaction的时候，是否和你的insert的prewrite时间超长的时候对的上。 我的经验是，一般偶尔的insert 慢查询，这种prewrite时间超长的时候都是tikv在compaction。

https://docs.pingcap.com/zh/tidb/stable/top-sql 要分析这种单台比较出挑的情况，推荐使用topsql界面看看这台执行的sql是那些。 还有就是，tidb的ddl只有一台owner负责执行，有可能是这个原因。

感觉恐怕不是文件合并能解决的问题。 因为目录里面看应该是一堆sst文件，这可能可以理解为就是region的原始信息，而且带了备份时间开始到现在的所有mvcc信息来实现pitr。这个东西恐怕不是文件合并能解决的。 因为会有一些sst没写满，按天还原sst肯定有相互的覆盖，按天操作一个顺序搞错，恢复的日志就没法用了。 如果非要一天上传一次，我感觉保险点还是每天tiup br log stop之后备份掉，再按照时间戳启动一下任务，并且改变一下保存的路径。可能可以做到。 我也没试过。你可以尝试一下。 最好还是弄个s3.就非常省心了。你这么绕一圈折腾的原因，还是因为用的是共享目录。