主从复制发生错误长时间未处理导致主服务器性能降低

背景

前两天某项目客户反馈系统卡顿，同事开始接手处理，对 MySQL 配置进行了缓存及线程部分参数的调整，直至昨天下午仍未解决卡顿问题。昨天下午我开始介入，复盘近期该项目所作的变更及发生的事件，想起在问题发生前几天同时反馈主从复制失效，当时上服务器执行show slave status看到 Error Code: 1677 ，当时综合考虑客户系统使用情况，决定暂不处理，也并未执行stop slave暂停复制。解决卡顿问题的第一件事就是先确定问题是发生在哪个环节，由于是全面卡顿，于是用 Arthas 先 trace 了一个较复杂的接口，发现耗时 99%都是集中在数据库访问，至此已经确认问题是出现在数据库，于是尝试关闭主从复制：stop slave并修改主服务器配置文件，将主从复制相关配置注释掉（想着晚上客户停用系统了再重新配置，于是把 binlog 也通过purge删掉了），重启 MySQL ，重启项目，暴力测试并观察了半个小时，未发生卡顿问题。

今早又出现卡顿，检查发现主从复制又报错了，stop slave没一会儿就恢复了……

环境说明

两套系统和 MySQL(主)部署在同一台服务器(Windows Server)，同局域网还有一台服务器部署了 MySQL(从)用于数据备份。

疑问

翻看 MySQL Reference Manual ，里面写基于 binlog 的复制是异步的，如图：

因此我认为主从复制线程不影响读写线程。

于是我开上到网上找原因，有相关文章提到 binlog 过长占用磁盘而影响到了 IO 性能，这个可能性似乎不大，我在昨天删除 binlog 文件前还看了一下文件大小，基本在 500kb 以下。

所以想请教大家，是什么原因导致 MySQL 主从复制在发生错误时导致了对 master 的查询(Query)性能大幅下降？