几十条确实不应该，如果不是我说的这个问题，且重启tidb也没用，那只能找研发来看看了

那可能就是这个问题，先把fast ddl关了，这样回滚就会快了，然后explain analyze select count(1) from table_name,看一下total_keys是否远大于真实的keys

是否开启了fast ddl,另外admin show ddl jobs看下行数执行了多少，如果是fast ddl开启，且有更多意外的版本信息就会有这种情况

机器之间有做时间同步么

此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。

确实感觉没啥问题，你把noteid索引去掉，或者把noteid的长度加长到255看下有没有效果呢，我这没有8.1的环境没法测试

两个怎么保证多副本存活，不能是两副本啊

1.你用dumpling备份下，正常应该是不会报错的，如果dumpling报错就有问题了 2.隐藏主键可以看下polardb官网文章：迁移本地MySQL至PolarDB MySQL_云原生数据库 PolarDB(PolarDB)-阿里云帮助中心

这个问题是已知问题，你这个表没有主键吧，阿里云对没有主键的表会给个隐式主键，你同步一个有主键的表

filters中的events去掉看看有没有效果，能起来不,https://docs.pingcap.com/zh/tidb/v6.5/task-configuration-file-full,你按照官方的写一下，你这个给的比较简化,看不太出来，按理说超级权限也应该是增量时候要的

dm的配置文件也脱敏发一下吧，还是dm日志里的详细报错

知道是polardb,确实是可以的，可能是你这个版本太低了吧，dm的版本是多少，还有polardb的版本

很奇怪，这就是超级权限了，你这个账号就一个么，你直接show grants;不加后面的for那些，结果也是一样的么

你show grants看下账号权限，replication slave，replication client，这两个本身就是super权限，你是不是有同名账号，ip段不同的情况

replication slave ,replication client这些应该能拿到吧。polardb应该没有限制啊，拿不到是什么限制

上下游表结构发下看看，都一样，还有sql_mode也发下

迁移账号权限给够了么，看报错是没有权限

好的，感谢大佬，我这里仔细对比了下监控，目前来看起来是因为对应kv节点的cpu较高导致的，当前情况下除了tikv_client重试次数升高外，99，999没有明显变化，暂时不做处理了

嗯呢，这个之前也看了，但是我这个80分以上的应该超过30秒了，这里还是想确定下，对于这种高压的场景（预计持续10-30min），是让leader如现在这种切换更好呢，调高阈值，让leader不做切换更好