如何解决MySQL主从复制中因字符集不一致导致的报错？-mysql教程-PHP中文网

last_errno: 1677 报错本质是主从同一张表的character set或collation不一致，须逐表比对show create table输出，用alter table ... convert to统一修复，同时确保主从character_set_server、collation_server及复制连接层配置完全一致。

如何解决mysql主从复制中因字符集不一致导致的报错？

直接结论：Last_Errno: 1677 报错几乎可以锁定是主从**同一张表**的 CHARACTER SET 或 COLLATION 不一致，不是“设个全局变量就能好”的问题，必须逐表比对并用 CONVERT TO 修复。

怎么确认真是字符集导致的 1677 报错

先看从库 SHOW SLAVE STATUS\G 输出里的 Last_SQL_Error，如果含类似 cannot be converted from type 'varchar(1536)' to type 'varchar(2048) utf8mb4' 或 Illegal mix of collations，基本就是它了。

接着分别在主、从库执行：

SHOW CREATE TABLE your_db.your_table\G

重点对比三处：

DEFAULT CHARSET=xxx（表级字符集）
COLUMN col_name VARCHAR(...) CHARACTER SET xxx（显式列字符集）
COLLATE xxx（表或列的校对规则，如 utf8mb4_unicode_ci vs utf8mb4_0900_ai_ci）

别只查 character_set_database —— 它只是默认值，建表时没写 CHARACTER SET 才会继承；真正起作用的是表自身定义。

改表字符集必须用 CONVERT TO，不能用 MODIFY 或 CHANGE

ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci 是唯一安全方式，它会同时转换数据内容、列定义、索引和默认校对规则。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

以下操作极易踩坑：

用 MODIFY COLUMN name VARCHAR(255) CHARACTER SET utf8mb4：只改列定义，不转已有数据编码，同步仍报错
漏写 COLLATE，比如只写 CONVERT TO CHARACTER SET utf8mb4：MySQL 会用默认 utf8mb4_general_ci，若主库原为 utf8mb4_unicode_ci，比较行为可能出错
表含外键或全文索引：CONVERT TO 可能失败，需先 DROP FOREIGN KEY 和 DROP INDEX，修复完再加回

MySQL 8.0 主从 collation 不兼容（如 utf8mb4_0900_ai_ci）怎么处理

从库是 MySQL 5.7 或早期 8.0 版本时，遇到 Unknown collation: 'utf8mb4_0900_ai_ci' 错误，本质是排序规则不被识别，不是字符集问题。

必须全链路统一替换为兼容版本：

导出 SQL 文件中所有 utf8mb4_0900_ai_ci → 替换为 utf8mb4_general_ci（5.7 原生支持，最稳妥）
检查 CREATE DATABASE 后的 DEFAULT COLLATE、每个 CREATE TABLE 末尾、以及单列定义后的 COLLATE
别用 --compatible=mysql57 试图自动降级——它不处理 collation，只改语法结构
从库启动后，还需确认 @@collation_connection 和 @@collation_server 是否也为 utf8mb4_general_ci，否则复制线程解析 binlog 时仍可能失败

为什么修完一张表还报错？根因在建表逻辑和 binlog 记录方式

问题常复发，是因为根本原因不在“当前这张表”，而在主从新建库/表时的默认配置不一致：

主库 character_set_server = utf8mb4，从库却是 latin1 → 主库没显式写 CHARACTER SET 的建表语句，在从库就按自己的默认值创建，表结构已不同
后续主库插入 emoji（需 utf8mb4），从库字段只支持 latin1 或旧 utf8，直接触发 Last_Errno: 1677

所以不能只修报错表，必须统一：