MySQLReplicationLag意想不到的原因在线有一个MySQL5.7的实例，从服务器延迟了30000多秒，而且延迟似乎还在增加。MySQL版本Serverversion:5.7.18-logMySQLCommunityServer(GPL)看下延迟状况yejr@imysql.com:mysql3306.sock:(none)>showslavestatus\GMaster_Log_File:mysql-bin.013225Read_Master_Log_Pos:1059111551Relay_Master_Log_File:mysql-bin.013161Exec_Master_Log_Pos:773131396Master_UUID:e7c35a95-ffb1-11e6-9620-90e2babb5b90我们可以看到binlog文件后面是64位，比较夸张。MySQL5.7不是已经实现了并行复制吗？为什么会有这样的延迟？首先检查系统负载。可以看出mysqld进程的负载其实并不算高，也没有出现SWAP等严重问题。查看I/O子系统的负载，这块没有瓶颈（await\svctm\%util不高）。查看mysqld进程的CPU消耗。虽然mysqld进程的CPU消耗总是超过100%，但并不算高。然后检查MySQL复制站点，确认几个经常更新的表有主键和必要的索引。排除没有主键和没有合理索引的因素，几乎都是基于主键或唯一索引条件进行相应的DML操作。***只能使用perftop神器。perftop-p`pidofmysqld`像这样查看perftop***的报告Samples:107Kofevent'cycles',Eventcount(approx.):29813195000OverheadSharedObjectSymbol56.19%mysqld[.]bitmap_get_next_set16.18%mysqld[.]build_template_field4。61%mysqld[.]ha_innopart::try_semi_consistent_read4.44%mysqld[.]dict_index_copy_types4.16%libc-2.12.so[.]__memset_sse22.92%mysqld[.]ha_innobase::build_template我们看到，bitmap_get_next_set这个函数调用占了56.19%，非常高，其次是build_template_field函数，占比16.18%。在查看了MySQL源码并咨询了MySQL内核开发专家后，最终确认这两个函数与开启表分区有关。查询当前实例有多少表分区：yejr@imysql.com:mysql3306.sock:(none)>selectcount(*)frompartitionswherepartition_nameisnotnull;+----------+|count(*)|+-----------+|32128|+------------+1rowinset(11.92sec)天哪，表分区有三万多，难怪上面两个函数调用这么高。这个业务数据库中的几张大表采用每天分区的方案，所有的分区都是提前创建到年底的，所以有这么多。不过，虽然有这么多表分区，但是在master服务器上并不存在这个瓶颈。看来这个瓶颈是因为主从复制的综合因素和大量的表分区，最终导致主从复制的延迟越来越大。一旦知道问题出在哪里，就很容易解决。删除所有直到下个月月底才用到的表分区，之后就只剩下16000左右的分区了。重启从线程，问题解决，主从复制延迟很快消失。
