这里吗 SELECT /*+ read_from_storage(tiflash[link1])*/ link1.* FROM leader_relate_link link1 JOIN ( SELECT link.id FROM 一样的 [image]

去掉一样慢

会话也是一样

放这里 走的是tikv [image] 设置变量 也没有warning

不行， [image]

原生是tikv，走的index join，现在是tikv写压力大，想缓解tikv压力走tiflash，让sql2 走sql1的执行计划，为什么sql2 没用到runtime_filter

这里的问题是 1、为什么执行计划不一样，能不能控制走一样的执行计划，数据量大小关系不大 2、慢的sql 子查询单独跑也很快，为什么一起跑就慢了

我觉得不是，如果生产库的大表都是AP请求， 你把副本数变为0， 业务不就打死tidb了吗

附件就有啊

不太一样，修复的是并行DDL, hash表重分区操作不是并行吧

可以看第二个日志，日志刷的太多。tiflash一直重复蹦了半个小时，直到强制下线才稳定 [image]

profile 文件 profiling_2025-06-26_17-02-39.tgz (2.0 MB)

生产7.5.4，先观察8.5.2有没有大坑，再决定升不升

【大家的 TiDB 集群数有多少】 生产4个，测试1个 【所在的公司有用海光服务器吗？使用数量有多少？】 没有 【除了海光服务器，目前在用的服务器品牌有哪些？】 浪潮、戴尔

8.5 没问题，看来是已知问题。7.5的小版本修复了吗

可以不用新建任务重新开始 1、 停止异常的任务 stop-task 任务名 2、找到最接近异常binlog 的position， 这里就是mysql-bin.018513，position 4。 3、在下游tidb修改dm_meta.任务名_syncer_checkpoint, 在schema和table为空的行，修改binlog_name和binlog_pos为你希望的起始点。 同时删除 exit_safe_binlog_name和exit_safe_binlog_pos 记录 [image] 4、启动任务，start-task

o ,现在就是这么处理的。 我还以为是别的方法，在原有的任务进行修改。 比如怎么修改dm_meta库的数据，来指定binlog 和position

咋跳啊，能帮忙指导下吗

设置的每个binlog大小是1G, 所以这个512肯定是损坏了。该怎么修复dm同步呢