MySQL主从字符集或排序规则不一致会导致索引失效和数据乱码，需逐层验证服务端、库表字段、连接层配置，并统一为utf8mb4_0900_as_cs。
MySQL主从架构下，若主库和从库的字符集或排序规则不一致，不仅会导致数据乱码，还可能让索引在从库上“悄悄失效”——明明建了索引，EXPLAIN却显示type: ALL、key: NULL，查询变慢甚至拖垮复制延迟。这不是偶然，是MySQL比较逻辑的必然结果。
核心问题不在“有没有字符集”，而在“哪一层不匹配”
主从不一致常发生在三处：服务端默认配置、库/表/列定义、客户端连接参数。只要其中任意一层在主、从两侧不同，就可能引发隐式转换，进而导致索引无法使用或数据写入解码错误。
查清主从各自的实际字符集与排序规则
别依赖“应该一样”，必须逐层验证：
-
服务端默认值（影响新建库/表）
在主库和从库分别执行：SHOW VARIABLES LIKE 'character_set_server'; SHOW VARIABLES LIKE 'collation_server';
-
数据库级定义
SELECT DEFAULT_CHARACTER_SET_NAME, COLLATION_NAME FROM INFORMATION_SCHEMA.SCHEMATA WHERE SCHEMA_NAME = 'your_db';
-
表与字段真实定义（最易被忽略）
SHOW CREATE TABLE your_table; SHOW FULL COLUMNS FROM your_table LIKE 'col_name';
注意看输出中
CHARACTER SET和COLLATE是否完全一致，尤其警惕utf8mb4_unicode_civsutf8mb4_0900_as_cs这类看似相似实则不兼容的组合。 -
当前连接层（复制线程自身也受此影响）
复制线程本质是一个特殊客户端连接，它会读取主库的 binlog 并在从库重放。其行为受从库的character_set_client、collation_connection影响：SELECT @@character_set_client, @@collation_connection;
若从库未显式配置，复制时可能按老默认（如
latin1_swedish_ci）解析主库发来的 utf8mb4 字符，造成比较失败或转换。
主从字符集不一致引发的两类典型故障
索引失效（从库查询变慢、复制SQL卡住）
比如主库字段是VARCHAR(100) COLLATE utf8mb4_0900_as_cs，但从库同字段是utf8mb4_unicode_ci。当从库执行WHERE name = '张三'时，MySQL发现两边 collation 不兼容，被迫对name列做隐式 CONVERT，B+树索引直接跳过。数据乱码（INSERT/UPDATE 后中文变问号或 Mojibake）
主库用utf8mb4插入，binlog 记录为合法 UTF-8 字节；但从库连接层用latin1解析这些字节，再存进utf8mb4字段 → 存进去就是错的，SELECT HEX() 可见C3A6C295C2A1这类二次编码痕迹。
修复动作需主从同步收敛，分三步推进
-
第一步：统一服务端默认（重启前可热生效部分）
在主库和从库的my.cnf[mysqld]段中添加：character-set-server = utf8mb4 collation-server = utf8mb4_0900_as_cs
注意：MySQL 8.0+ 推荐用
utf8mb4_0900_as_cs（大小写敏感、音调敏感），替代已弃用的utf8mb4_unicode_ci。修改后需重启 mysqld 才对新创建库生效。 -
第二步：校准存量库、表、字段（避免复制中断）
- 修改数据库默认：
ALTER DATABASE your_db CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_as_cs;
- 修改表及所有字段（含索引列）：
ALTER TABLE your_table CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_as_cs;
⚠️ 大表操作会锁表重建，建议在低峰期执行，并确认主从复制已暂停或处于可控状态。也可分批
MODIFY COLUMN，但务必保证 collation 完全一致。
- 修改数据库默认：
-
第三步：约束复制线程连接行为（关键！）
MySQL 复制线程默认不带字符集声明，容易 fallback 到服务端旧默认。需强制其使用统一 collation：
在从库配置文件[mysqld]中增加：init_connect='SET NAMES utf8mb4 COLLATE utf8mb4_0900_as_cs'
或更精准地，在启动复制前手动设置（适用于临时修复）：
STOP SLAVE; SET GLOBAL init_connect = 'SET NAMES utf8mb4 COLLATE utf8mb4_0900_as_cs'; START SLAVE;
验证是否生效：
SHOW SLAVE STATUS\G -- 查看 Seconds_Behind_Master 是否回落，同时在从库执行： SELECT @@collation_connection; -- 应返回 utf8mb4_0900_as_cs
补充验证点：别只信“看起来一样”
- 在主库插入一条含中文和 emoji 的测试数据（如
'测试?'），查SELECT HEX(col)确认存储为E6B58BE8AF95F09F9A80（UTF-8 四字节）； - 登录从库查同一行，
HEX()结果必须完全相同；若变成C3A6C2B5C28BE8C2AFC295，说明已在复制途中被错误转码； - 对关键查询执行
EXPLAIN，主从两侧key、rows、Extra字段必须一致；若有差异，大概率是 collation 不匹配触发了隐式转换。
不复杂但容易忽略
