Last_Errno: 1677 报错本质是主从同一张表的CHARACTER SET或COLLATION不一致，须逐表比对SHOW CREATE TABLE输出，用ALTER TABLE ... CONVERT TO统一修复，同时确保主从character_set_server、collation_server及复制连接层配置完全一致。
直接结论：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_civsutf8mb4_0900_ai_ci）
别只查 character_set_database —— 它只是默认值，建表时没写 CHARACTER SET 才会继承；真正起作用的是表自身定义。
改表字符集必须用 CONVERT TO，不能用 MODIFY 或 CHANGE
ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci 是唯一安全方式，它会同时转换数据内容、列定义、索引和默认校对规则。
以下操作极易踩坑：
- 用
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
所以不能只修报错表，必须统一：
- 主从
my.cnf中character-set-server和collation-server配置一致 - 所有 DDL 显式声明
CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci - 导出备份时加
--set-gtid-purged=OFF（GTID 环境）或确保--master-data=2生效，避免恢复时位置错乱
最容易被忽略的是连接层：复制线程本身是一个客户端连接，它的 character_set_client 和 collation_connection 若没配对，binlog 里的字节就会被错误解码——哪怕表结构完全一致，照样乱码或报错。
