看下analyze的时间点，show analyze status,是不是有analyze执行失败的情况，另外调整下analyze的时间观察下cpu有没有明显下降，先排查下是否为analyze的问题

表多大，满足条件的数据量多大，查询的字段有没有大字段，关联字段有没有索引，如果需要扫描和join的行数很多，确实会超过你设置的内存，你说内存只用了几十G，是因为你限制了20G，所以内存也不会更大，如果确定没有影响，且查询没有优化（必须加索引，换join方式）那只能加大参数了

有个类似的issuse,但是显示已经合并并发布了，按理说不会有这个问题，你这个备份是什么时候备份的，备份的命令是什么，备份到现在这段时间字符集之类的有没有改过 https://github.com/pingcap/tidb/issues/31297

可以发下执行的命令和报错的日志么

show variables like ‘%character%’;show variables like ‘%collation%’;上下游执行下这两个，看下结果

从cdc测直接解析出来是几条数据，应该也是多条，而不是一条吧

下游是什么，cdc的配置是什么样，正常不应该有这个问题

偶现就太奇怪了，没有规律么，没有其他人有操作权限么

那使用下非限制RU的用户跑一下这个任务，看会不会有问题，也有可能是RU这块的问题，如果是的话再找找是否有对应的bug

用那个用户执行的呢，查下那个用户有没有配置一些runaway,资源管控的那些配置，正常也不会配置到3s啊感觉

执行耗时多长，有设置过max_execution_time之类的参数么

这个提示不明显是有对应的issue的，https://github.com/pingcap/tidb/issues/49940，但是看起来也是回填报错，应该还是数据重复吧

单行数据大小限制，如果表里面有text,mediumtext等大文本的字段，一定要事先和开发确定下最大内容能存到多大，及时调整配置，避免业务故障

这种写个脚本处理就好吧

目前没有手动恢复的方式，如果用unsafe-recover可以恢复，但比较复杂，且没有必要，你数据盘多大，使用率多少啊

没有了，其他命令也是你到对应的机器跑脚本，不过都是一样的，启动就两个命令，start和restart，扩缩容相关可以看文档：https://docs.pingcap.com/zh/tidb/v7.5/scale-tidb-using-tiup/#使用-tiup-扩容缩容-tidb-集群

对，正常来说都不会有数据问题的，只有异常宕机才会有

对，如果起不来只能这样了，如果你检测了当前机器磁盘等没有问题，且存储空间足够，也可以在当前机器新扩容个节点，改下端口和数据目录等，一般这种数据出问题的情况都是异常断电之类的，你这种就比较奇怪

那应该不是机器的原因了，让机房检查下磁盘是不是有问题吧，当前tikv的问题就是某些原因导致了数据损坏，某些提交数据出了问题，你启动启不起来的话就扩容再缩容挂掉的kv节点吧