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.就非常省心了。你这么绕一圈折腾的原因，还是因为用的是共享目录。

能看到ru_comsumption=0. 如果不是资源组和用户绑定有问题，那可能就是像楼上说的那样。资源组的ru用完了，实在没ru给他了。导致等待时间巨长。 看看执行计划里面是否有具体的信息。

cpu都没跑满，这个测试就属于没压到位啊。 当然cpu跑满了，也可能跑不过单机mysql。 还是建议先压满cpu，再考虑调优。

看这个，里面写道： selectResult 实现了 SelectResult 这个接口，代表了一次查询的所有结果的抽象，计算是以 Region 为单位进行，所以这里全部结果会包含所有涉及到的 Region 的结果。调用 Chunk 方法可以读到一个 Chunk 的数据，通过不断调用 NextChunk 方法，直到 Chunk 的 NumRows 返回 0 就能拿到所有结果。NextChunk 的实现会不断获取每个 Region 返回的 SelectResponse，把结果写入 Chunk。 所以结论是按chunk分批拿结果。