MySQL跨服务器复制乱码主因是主从character_set_server不一致，须统一为utf8mb4并持久化配置；mysqldump导出导入需全程显式指定--default-character-set=utf8mb4，且应用连接必须初始化时设charset='utf8mb4'。
MySQL 跨服务器复制时 character_set_server 不一致导致的乱码
跨服务器复制出现中文变问号、 mojibake 或 符号，大概率是主从的 character_set_server 值不一致，而非表或列的字符集本身有问题。mysql 复制默认不校验字符集兼容性，一旦主库用 utf8mb4 写入，从库以 latin1 或旧版 utf8 解析，就直接丢字节。
- 查主从当前值：
SHOW VARIABLES LIKE 'character_set_server'; - 必须两端完全一致，推荐统一为
utf8mb4（不是utf8） - 修改需重启 MySQL 或动态设（仅对新连接生效）：
SET GLOBAL character_set_server = 'utf8mb4';，但持久化必须改配置文件my.cnf的[mysqld]段落 - 注意：改完
character_set_server不会自动转换已有表，需单独ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4;
mysqldump 导出导入链路中的编码断层
用 mysqldump 中转数据时，乱码往往发生在「导出 → 文件保存 → 导入」三步里任意一环编码没对齐。尤其容易忽略终端、SSH 客户端、文本编辑器本身的编码设置。
- 导出必须显式指定编码：
mysqldump --default-character-set=utf8mb4 -u user db > dump.sql；漏掉--default-character-set会按客户端默认（常为latin1）读取，即使表是utf8mb4也照样错 - 生成的
dump.sql文件本身是二进制流，不是“UTF-8 文本”——它的编码由 mysqldump 决定，和你本地编辑器打开时用什么编码无关 - 导入时也要带参数：
mysql --default-character-set=utf8mb4 -u user db ；否则 mysql 客户端可能用错误编码解析 SQL 流 - 如果用
source命令导入，必须先在 mysql 会话里执行：SET NAMES utf8mb4;
SSH + 远程命令管道复制时的终端编码干扰
用 ssh user@host "mysqldump ..." | mysql ... 这类管道方式跨服务器同步，乱码通常不是 MySQL 层的问题，而是 SSH 会话的 LANG 和 LC_ALL 环境变量影响了 mysqldump 的输出编码。
- 远程执行前强制指定环境：
ssh user@host "LANG=C.UTF-8 LC_ALL=C.UTF-8 mysqldump --default-character-set=utf8mb4 db" - 本地终端的
LANG若是zh_CN.GB18030或其他非 UTF-8，可能让管道中间截断多字节字符，表现为导入后字段开头或结尾缺字 - 避免在管道中用
sed、awk处理 SQL 流——它们默认按字节处理，遇到utf8mb4四字节字符极易劈开，产生非法序列
应用层直连双库写入时的连接参数遗漏
有些业务逻辑绕过复制，直接用代码同时往主从写，这时乱码根源常在 JDBC/PHP/PDO 的连接字符串里没声明字符集，导致连接建立后默认用服务器旧值，而应用层又没执行 SET NAMES。
- JDBC URL 必须含：
?useUnicode=true&characterEncoding=utf8mb4（注意是utf8mb4，不是utf8） - PHP mysqli：连接后立刻执行
$mysqli->set_charset('utf8mb4');，不能只靠mysqli_options($mysqli, MYSQLI_INIT_COMMAND, "SET NAMES utf8mb4"); - Python PyMySQL：构造连接时传参
charset='utf8mb4'，且确保init_command="SET NAMES utf8mb4"也设上 - 关键点：字符集声明必须在连接建立时完成，不能等执行 SQL 前才临时
SET，因为某些驱动会把建连后的第一条语句当初始化命令，延迟生效
真正麻烦的不是设哪个值，而是整个链路里有至少 5 个独立控制点（服务端变量、客户端参数、dump 工具选项、SSH 环境、应用连接配置），任一环节掉链子，数据就静默损坏——而且很难回溯哪一环出的问题。
