主从同步乱码源于主库写入与从库解析字符集不一致，需分别检查主库会话级character_set_client/connection/results是否均为utf8mb4，以及从库SQL线程的对应变量；binlog格式影响解码方式，STATEMENT要求主从字符集严格一致，ROW依赖主库写入时编码正确；修复已乱码数据须回溯原始字节流，CONVERT单独使用无效。
主从同步中出现乱码，不是数据“被改了”，而是主库写入时用的字符集和从库解析时用的不一致——最常见的是主库会话用了 utf8mb4，但从库 SQL 线程却按 latin1 或旧 utf8 解析 binlog，导致中文变成 æ‘ 这类 MojiBake。
查主库写入时的真实字符集
乱码源头一定在主库写入那一刻。不能只看表定义或服务器默认值，得确认当时执行 INSERT/UPDATE 的会话级设置：
- 登录主库，执行
SHOW VARIABLES LIKE 'character_set%';，重点核对character_set_client、character_set_connection、character_set_results是否全为utf8mb4 - 如果应用是 JDBC，检查连接 URL 是否含
characterEncoding=utf8mb4；PHP 要确认是否调用过mysqli_set_charset($conn, 'utf8mb4') - 若主库是脚本批量导入，务必在第一行加
SET NAMES utf8mb4;—— 仅靠配置文件或建表语句无法覆盖会话初始编码
查从库 SQL 线程的字符集上下文
从库不是“读表”，而是重放主库的 binlog event。SQL 线程有自己的会话环境，它用什么字符集解析 event，直接决定最终存进从库的数据是否正确：
- 登录从库，在运行中执行
SELECT * FROM performance_schema.threads WHERE TYPE = 'FOREGROUND' AND PROCESSLIST_COMMAND = 'Query';找到 SQL 线程 ID，再查其变量：SELECT VARIABLE_VALUE FROM performance_schema.session_variables WHERE THREAD_ID = ? AND VARIABLE_NAME IN ('character_set_client', 'character_set_connection', 'character_set_results'); - 更简单的方法：在从库上执行
STOP SLAVE; SET NAMES utf8mb4; START SLAVE;，然后观察是否不再新增乱码 —— 如果有效，说明 SQL 线程默认没继承主库的字符集 - 注意：从库的
my.cnf中[mysqld]段的character-set-server不影响 SQL 线程解析逻辑，真正起作用的是 SQL 线程启动时的会话变量
检查 binlog 格式与 event 内容
binlog 本身不存字符集元信息，但格式会影响字段值如何被序列化：
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 如果主库是
STATEMENT格式，SQL 语句（如INSERT INTO t VALUES ('你好')）以文本形式记录，从库必须用和主库**完全相同的字符集**去 decode 字符串字节流，否则必然错位 -
ROW格式相对安全，因为字段值以二进制形式记录，但前提是主库写入时字段本身已按正确字符集编码 —— 若主库写入时就用了latin1存中文，那 ROW event 里存的就是错的字节，从库照搬也还是乱码 - 验证方法：用
mysqlbinlog --base64-output=DECODE-ROWS -v查看具体 event，搜索中文字符串的十六进制表示（如xE4xBDxA0xE5xA5xBD是 UTF-8 编码的“你好”），再对照主库当前character_set_client判断该字节流是否应被解释为 UTF-8
修复已乱码的从库数据
一旦乱码进入从库，CONVERT(column USING utf8mb4) 失效——因为源数据已是错误解码后的垃圾字节，不是原始 UTF-8 字节流：
- 最可靠方式：停从库，导出主库当前正确数据（用
mysqldump --default-character-set=utf8mb4），清空从库对应表，再导入 - 若只能在线修复，且确认主库原始数据仍完好，可尝试在从库上对乱码字段执行
UPDATE t SET col = CONVERT(CAST(CONVERT(col USING latin1) AS BINARY) USING utf8mb4);—— 这是在模拟“把错解的 latin1 字节先转回 binary，再当 UTF-8 重解”，但成功率取决于乱码类型，不保证 100% - 切记：ALTER TABLE MODIFY COLUMN 改字符集，不会重解已有内容，只是修改元数据；真正重解需配合 CONVERT + CAST 组合操作
主从字符集问题最难缠的地方在于：它可能只在特定客户端、特定连接方式、特定 binlog 格式下触发，且现象滞后（主库看着好好的，从库几天后才暴雷）。所以不要只查“现在是什么”，而要抓“当时写入那一刻，主库用什么编码发的字节，从库用什么编码收的字节”。
