方便提供一个执行计划嘛？ 执行计划里面有很多信息可以帮助改善，不然凭空猜是有点不知道为啥。

不用测，搞个profiling看就好了。 https://docs.pingcap.com/zh/tidb/stable/dashboard-profiling

没开mpp模式？不然不应该的。一开应该是很快资源就不够用了才对。 楼上说的对，找几个执行计划来看看是什么回事。

前半段是对的，这个修复方法的关键在于，把binlog拷贝过来当作relay log使用，relay log这块是dm自己实现的，可以绕开4g。 所以你后半的理解差一步。前半是对的。 你就看看dm_meta库里面[task-name]-_syncer_checkpoint这个表里面还有没有 31354389这个数字。这个global checkpoint的地方可能是漏改了。

这个帖子你可以翻一下，处理方法和楼上的大同小异。 不过从机制上讲，当一个节点被判断为slow ，readpool应该是有排队现象的。对整体的QPS应该是一种保护。

不能手动刷，不过最大的flush时间是可以配置的。应该和下面这个参数有关。默认的情况等3分钟应该就可以算是flush了。 https://docs.pingcap.com/zh/tidb/stable/tikv-configuration-file#max-flush-interval-从-v620-版本开始引入

mysql主从也有这个问题。感觉问题的核心在于 就是当binlog文件大于4G的时候，因为发送的位点是一个uint32类型的，这里大于4G会出现截断 position在mysql里面是个uint32存放的，大于4g就溢出了。 这成了个mysql的硬伤，只能从分拆大事务的方向去解决了。到了dba这里，没什么特别好的办法了。

这块即使不是一个bug，也应该是一个可以优化的地方。

表空间不用管，没这东西。 插件功能主要用于审计，付费用户才有。你没付钱也不用担心这个。如果你付了钱，可以直接找商业支持。 https://docs.pingcap.com/zh/tidb/v8.4/sql-statement-show-plugins 查看有没有插件，直接 SHOW PLUGINS;

和br有关，是有点令人费解。 tiup br升级到和tidb一样的版本，重新建立br快照备份和日志备份呢？ 或者看看以前的br log备份是有什么问题嘛？ 不过如果cdc是全量往别的地方发送数据的话，br确实可有可无。如果cdc不是全量，没有br pitr备份还是稍微有点不踏实。

我感觉你的意思更像是个bug反馈而不是一个问题等待解决，问题好像已经被你解决了？ 如果是bug反馈，可以直接尝试去提个issue。

这要结合你的sql查询是什么样的来看的。 你的sql是根据id的点查多，那么现在确实是有点难办。因为id已经没法变成全局索引了。然后id又不是分区列，如果不带分区列的id点查，是不好裁剪分区。 这种情况现在确实是除了重建表没有更好的办法了。 但我感觉实际情况大概率没这么差，因为真要这样，你早就发现性能没法用。所以你大概率现在根据id的点查，已经是带着分区列和id的了。 那么这种sql不用全局索引，我估计性能也不会差很多的。

我找了半天，确实没找到schema id该怎么找schema。 如 @Brian 所说table id已经是唯一的话，那确实可以直接从tables表里面找schema是什么。

另外提一下4.0.2版本太低了，要升级了。 整个4.x版本都已经EOL了。 https://cn.pingcap.com/tidb-release-support-policy/ 还能维护的最小版本也是5.4了。

[image] 执行计划上看这就是个完完全全的扫描任务，不带任何聚合。 问题的关键是这个语句本不该走tiflash。 然后你用tidb_isolation_read_engines参数强制他只能从tiflash上读取，并发一高就是会很慢。

这版本有点低，可能需要重启一下pd。

那基本可以确定问题在os了。

https://docs.pingcap.com/zh/tidb/stable/dynamic-config#在线修改集群配置 通过set config，把block-cache这个值往下调，oom说明29g还是大了。 改了不会立刻生效，但是半小时内，肯定能看到下去了，没下去说明还是大了，继续往小了改。 我在8G内存的机器上都能通过这个控制住不发生oom。64g肯定能控制住的。 在线改的合适了，记得tiup cluster edit-config 改一下配置文件。

目前报告上来的还都是tidb节点在rocky上如果内存不够有卡死的问题。tikv还没有收到报告。 是指同样的内存大小，同样的block-cache大小的情况下，也会大20%内存吗？如果是，问题可能还在os的内核里面。 tikv和tidb用的编译语言不一样，本来tidb可能还要排除go版本的影响，如果能确认，那么go版本应该对这个问题是没有影响的。