切换为utf8mb4后MySQL数据同步速度骤降问题排查求助

作为经常处理MySQL迁移和性能问题的人，我来给你梳理几个排查方向，帮你定位这次改完utf8mb4后同步速度变慢的原因：

1. 先从MySQL数据库本身找线索 #

检查慢查询日志 #

首先开启慢查询日志，看看同步时执行的SQL语句是不是出现了明显的延迟：

• 临时开启慢查询：set global slow_query_log = 1;，可以设置慢查询阈值比如set global long_query_time = 1;（超过1秒的语句都会记录）
• 日志默认路径一般在/var/log/mysql/slow.log（不同系统可能有差异），查看里面同步相关的INSERT/SELECT语句，看执行时间是不是比之前大幅增加。如果某条语句突然变慢，那大概率是问题所在。

验证表的字符集是否同步更新 #

你只改了数据库级别的字符集，但现有表的字符集不会自动跟着改变！这很可能是关键：

• 执行show create table your_table_name;，看看表的CHARSET是不是还是原来的utf8。如果是，那插入数据时MySQL会自动在utf8和utf8mb4之间做编码转换，批量插入时这个开销会非常大，直接拖慢速度。
• 如果表确实还是旧编码，建议把表也改成utf8mb4：alter table your_table_name convert to character set utf8mb4 collate utf8mb4_unicode_ci;（注意备份数据再操作）

查看MySQL状态变量找瓶颈 #

执行以下命令，看有没有异常的状态指标：

• show status like 'Innodb_row_lock_waits';：如果数值很高，说明有行锁等待，可能是同步时和其他操作冲突，或者批量插入导致锁竞争。
• show status like 'Handler_write';和show status like 'Innodb_data_writes';：对比改编码前后的写入次数，看是不是因为单条记录字节数增加（utf8mb4比utf8多1字节）导致写入量变大，触发IO瓶颈。
• show variables like 'innodb_buffer_pool_size';结合show status like 'Innodb_buffer_pool_reads';/show status like 'Innodb_buffer_pool_read_requests';：计算缓存命中率（1 - (Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests)），如果命中率低于99%，说明缓存不够，大量请求落到磁盘，拖慢速度。

2. 排查网络和EC2实例性能 #

检查EC2之间的网络状况 #

虽然你换过实例，但还是要确认两台EC2的连通性有没有变化：

• 用ping target_ec2_ip测试延迟，看看平均延迟是不是比之前高；用mtr target_ec2_ip看有没有丢包情况。
• 因为utf8mb4会让包含表情的记录字节数增加，如果同步是跨网络传输数据，可能会因为单条记录变大导致吞吐量下降。可以用scp传一个1G左右的文件，看看传输速度是不是正常。

查看EC2的系统资源瓶颈 #

去AWS CloudWatch或者直接在实例上用命令看资源使用：

• CPU：top或者htop看CPU使用率，如果同步时CPU跑满，可能是编码转换或者SQL执行占用了大量CPU。
• 磁盘IO：iostat -x 1看磁盘的%util，如果接近100%，说明磁盘IO是瓶颈。改编码后如果表需要转换，或者同步时写入量变大，都会加重磁盘负担，这种情况可以考虑升级EBS卷的IOPS，或者换用IO优化型实例。

3. 检查同步代码的连接和逻辑 #

确认mysqlclient的连接参数 #

改了数据库编码后，你的同步代码连接MySQL时有没有指定charset=utf8mb4？

• 如果连接时还是用charset=utf8，客户端和服务端之间会频繁做编码转换，这会带来额外的性能开销。确保连接字符串里包含charset=utf8mb4（比如Python里的connect(..., charset='utf8mb4')）。

检查同步逻辑的变化 #

有没有因为之前的表情问题，修改了同步代码的逻辑？比如：

• 把批量插入改成了单条插入？
• 增加了对每条记录的表情检测/处理逻辑？
• 批量插入的大小变小了？
  这些都会直接影响同步速度，你可以对比上周五的代码版本，看看有没有这类改动。

4. 其他可能的点 #

• 确认skip-name-resolve是否真的生效：执行show variables like 'skip_name_resolve';，如果返回ON才是生效的，这个参数主要解决DNS解析慢的问题，但如果已经开启了还没效果，那问题不在这。
• 检查MySQL的后台任务：比如改完编码后有没有自动的表优化、碎片整理在后台运行？可以用show processlist;看有没有长时间运行的后台进程。

先从慢查询日志和表字符集这两个点入手，这两个是最常见的改编码后变慢的原因，排查起来也最快。

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