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_ci vs utf8mb4_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 才对新创建库生效。

  

  MySQL

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

  下载

• 第二步：校准存量库、表、字段（避免复制中断）

  • 修改数据库默认：

    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 不匹配触发了隐式转换。

不复杂但容易忽略