这个执行从超长的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分批拿结果。

给的信息还是太少。 先从grafana -》fast tune里面找找看，是否能快速找到一些有价值的信息。 这是手册。

tidb-loadbalance代码库的位置在这里，找了下没有发现report字样。 建议在自己的代码里面检索一下report，看看是否能找到些什么。

上面只是创建了一个资源组，还需要你绑定资源组到用户。 是不是有些用户绑的不是这个资源组，所以就不受你上面这个配置的限制。 https://docs.pingcap.com/zh/tidb/stable/tidb-resource-control#查看-sql-的-ru-消耗 另外文档中由上面这些方式可以看到sql对应ru消耗。建议发出来。可能对问题的定位会有所帮助。

你中控机都找不到还要重启这个tikv实例？你确定这样不会背锅嘛？ 如果是离职交接的原因该叫就叫啊。现在叫不会是你的错，但是你不叫，重启出了问题，肯定就是你的问题了。

[ERROR] [grpclogger.go:116] ["[transport]transport: Got too many pings from the client, closing the connection."] [system=grpc] [grpc_log=true]" [ERROR] [grpclogger.go:116] ["[transport]transport: loopyWriter.run returning. Err: transport: Connection closing"] [system=grpc] [grpc_log=true] 你日志里面这个b…

这应该是个bug。没有发现有hint导致不能mpp。