【 TiDB 使用环境】生产环境
【 TiDB 版本】4.0.6
dumpling导出的文件里，表结构文件里是没有这行的：
/!40101 SET NAMES binary/;
但数据sql文件是有的，这样就导致了，当下游为MySQL或者OB，使用myloader导入时，会导致目标的COMMENT为乱码。
请问大佬们这个有的解吗？查阅了很多资料，dumpling也没什么字符集参数，难道只能用mydumper进行导出？
你文本文件查看也是乱码的，是不是源库本来存的就是乱码的呢 
这不是文本，这是show create table xx\G出来的
那你 show 出来都不对了，你觉得有问题吗 
新建一张带 comment 的表，查看下是否乱码
然后从数据字典里看数据字典中存储的字符，使用 16 进制查看，判断是否之前存储的就有问题
八成是有问题的，对有问题的表，重新 comment 一下
大佬们可能没懂我的意思
这是导入进去之后show的，dumpling导出的东西，导入到tidb都是没问题，但是导入到MySQL或者OB ，因为表结构文件没有/!40101 SET NAMES binary/; 会导致导入后是乱码。
数据文件是有/!40101 SET NAMES binary/; 所以导入后，数据没问题，表结构的COMMENT如果有中文，就会出现乱码
请先检查源端数据库内是否有问题
源库没有问题，主要是导入后 所有表都这样，换了个源实例也是这样
我是批量用脚本把 /!40101 SET NAMES binary /;刷进去表结构的文件第一行，然后再导入就OK了。
只是想问下有没有不用二次加工的法子
可能需要先看本地客户端字符集问题。
dumper是会，但dumpling不会
看错了哈，set names语法兼容tidb&mysql 好像只能手动处理了
但是根源是不是还在源上？这三个都是什么值（ SET NAMES 'charset_name' 语句其实等于下面语句的组合：）
SET character_set_client = charset_name;
SET character_set_results = charset_name;
SET character_set_connection = charset_name;
手工处理吧。源端目标端字符集是一致的么？