如何在pt-online-schema-change中忽略MySQL 1300警告？

嘿，我帮你梳理下解决这个问题的方案——你说的没错，这个1300警告虽然不会中断复制进程，但堆在日志里看着闹心，还可能埋下数据不一致的隐患。下面给你两种思路的解决办法，按需选择：

一、临时跳过这类警告（快速见效） #

如果只是想先让复制日志干净点，不影响业务运行，可以调整MySQL的复制或sql模式参数：

• 设置从库跳过指定错误：在复制从库上配置slave_skip_errors参数，把1300加入跳过列表。这个操作分临时和永久两种：

  -- 临时生效（重启从库后失效，需要SUPER权限）
  SET GLOBAL slave_skip_errors = '1300';
  -- 永久生效，修改my.cnf/my.ini后重启从库
  [mysqld]
  slave_skip_errors = 1300
  

  注意：确认1300确实只是警告级错误，不会导致主从数据不一致再用这个方法。
• 关闭严格字符检查的sql模式：如果你的业务场景允许，可以临时移除NO_INVALID_CHARACTERS这个sql模式选项，避免MySQL检测这类无效字符：

  -- 会话级临时修改（仅当前连接生效）
  SET sql_mode = REPLACE(@@sql_mode, 'NO_INVALID_CHARACTERS', '');
  -- 全局永久修改，修改后重启MySQL生效
  [mysqld]
  sql_mode = "保留你现有其他模式，去掉NO_INVALID_CHARACTERS"
  

二、彻底修复无效字符问题（长治久安） #

从长期来看，修复数据本身的编码问题比忽略警告更稳妥，避免后续出现更严重的故障：

• 定位源库中的无效数据：先找到包含94C494这个无效字节序列的行，用下面的SQL可以快速排查：

  SELECT * FROM 你的数据表 WHERE CONVERT(目标字段 USING utf8mb4) IS NULL;
  

  找到对应行后，可以手动修正字符，或者用REPLACE函数替换无效字节（注意先备份数据再操作）。
• 确保主从编码参数一致：检查主库和从库的character_set_server、character_set_database、collation_server等编码相关参数，保证两边都是utf8mb4编码，避免复制过程中出现编码转换错误。
• 导入数据时忽略无效行：如果是通过数据导入触发的问题，可以在INSERT或LOAD DATA语句中加上IGNORE选项，让MySQL自动跳过包含无效字符的行：

  INSERT IGNORE INTO 目标表 SELECT * FROM 源表;
  

最后提个醒：跳过警告只是权宜之计，优先建议彻底修复编码问题，毕竟数据的完整性和一致性才是核心。

内容的提问来源于stack exchange，提问作者Brian Leishman