1677或Unknown collation错误源于主从字符集与校对规则不一致，需同步修复服务端配置、表定义及复制连接三层：统一my.cnf的character-set-server和collation-server，用CONVERT TO修改表，确保复制线程连接层字符集匹配。
Last_Errno: 1677 或 Unknown collation 错误，基本可以断定是字符集或校对规则在主从之间没对齐，不是单点配置能解决的，必须同时处理服务端、表定义、复制连接三层。
怎么确认确实是字符集问题引发的 1677 报错
先看从库 SHOW SLAVE STATUS\G 输出里的 Last_SQL_Error 字段：如果出现类似 cannot be converted from type 'varchar(1536)' to type 'varchar(2048) utf8mb4' 或 Unknown collation: 'utf8mb4_0900_ai_ci'，就基本锁定了。
接着对比主从两端同一张表的建表语句：
- 主库执行：
SHOW CREATE TABLE your_db.your_table\G - 从库执行同样命令
- 重点比对输出中三处：表级
DEFAULT CHARSET、每个字段定义里显式写的CHARACTER SET和COLLATE（别只看character_set_database，它只是默认值，不决定实际生效的字符集）
统一主从 character_set_server 和 collation_server
这是所有新建库/表的源头。如果主从 my.cnf 的 [mysqld] 段落里没显式设，各自会按不同默认值走，后续建表就天然不一致。
必须在主从两端都加上：
character-set-server = utf8mb4 collation-server = utf8mb4_unicode_ci
然后重启 MySQL。注意：SET GLOBAL character_set_server = 'utf8mb4' 只对新连接生效，且不持久，不能替代配置文件修改。
如果是 MySQL 8.0 主 + 5.7 从，utf8mb4_0900_ai_ci 从库根本不认识，得统一换成 utf8mb4_general_ci —— 它在 5.7 全版本原生支持，兼容性最稳。
用 CONVERT TO 修复已有表，不是 MODIFY COLUMN
ALTER TABLE your_table CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci 是唯一安全的全量迁移方式。它会同时转换列数据、列定义、索引和默认校对规则。
以下操作容易踩坑：
- 用
MODIFY COLUMN xxx VARCHAR(255) CHARACTER SET utf8mb4：只改单列定义，不改已有数据编码，也不影响其他列和索引，同步时仍可能报错 - 漏掉
COLLATE：比如只写CONVERT TO CHARACTER SET utf8mb4，MySQL 会用默认utf8mb4_general_ci，但如果主库原表是utf8mb4_unicode_ci，从库重放时可能因比较逻辑差异报错 - 含外键或全文索引的表要提前验证：
CONVERT TO可能失败，需先删后加，生产环境务必提前测试
检查并修正复制线程自身的连接层字符集
复制线程本质是一个特殊客户端连接，它的行为受从库的 @@character_set_client 和 @@collation_connection 控制。
执行：SELECT @@character_set_client, @@collation_connection;
如果返回不是 utf8mb4 和 utf8mb4_unicode_ci（或你选定的统一 collation），说明复制线程正在用错误的编码解析 binlog 字节流——哪怕表结构完全一致，也可能在解析阶段就出错。
解决办法是在从库 my.cnf 中加：
init_connect = 'SET NAMES utf8mb4 COLLATE utf8mb4_unicode_ci'
注意：这个设置对有 SUPER 权限的用户（比如复制线程）默认不生效，所以还得确保复制账户没有 SUPER 权限，或者改用更底层的方式（如启动参数 --default-collation=utf8mb4_unicode_ci）。
真正麻烦的点在于：这三处（服务端配置、表定义、复制连接）只要有一处没对齐，就可能在某个 DML 或 DDL 后突然触发报错，而且往往不是立刻暴露，而是延迟到某次更新、某次索引重建时才崩。所以修完别急着上线，得用真实业务流量压测一段时间。
