cdc直接就可以过滤的，具体看文档：https://docs.pingcap.com/zh/tidb/v7.5/ticdc-filter/#event-filter-事件过滤器-span-classversion-mark从-v620-版本开始引入span

明白，那这种路由功能CDC目前是不支持的，想要实现的话只能用cdc写到kafka中，然后自己消费来处理

在配置文件里写，你是不是想问ticdc支持路由功能不，比如上有库名为table_a,同步到下游库名table_b中，这个是不支持的，ticdc目前没有路由功能

这种可以，完全没冲突

是分库分表的场景么，同步到同一个表中还是不同表中

看下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等大文本的字段，一定要事先和开发确定下最大内容能存到多大，及时调整配置，避免业务故障

这种写个脚本处理就好吧