mysql5.7 system lock_MySQL：从库出现system lock的原因分析与解决方法

本文为笔者之前写一篇说明性文章，发现很多同学都在问这个问题，因此做一次分享。

本文基于5.7.17源码

本文只考虑row格式binlog

主要考虑DML语句，DDL语句比较简单不做考虑

以单sql线程为例(非MTS)

一、延迟的计算方式

其实每次show slave status命令的时候后台会调用函数show_slave_status_send_data进行及时计算，这个延迟并不是保存在哪里的。栈帧如下：

#0  show_slave_status_send_data (thd=0x7fffd8000cd0, mi=0x38ce2e0, io_gtid_set_buffer=0x7fffd800eda0"e859a28b-b66d-11e7-8371-000c291f347d:42-100173",

sql_gtid_set_buffer=0x7fffd8011ac0"e859a28b-b66d-11e7-8371-000c291f347d:1-100173")at/MySQL/MySQL-5.7.17/sql/rpl_slave.cc:3602

#1  0x0000000001867749 inshow_slave_status (thd=0x7fffd8000cd0)at/MySQL/MySQL-5.7.17/sql/rpl_slave.cc:3982

#2  0x0000000001867bfa inshow_slave_status_cmd (thd=0x7fffd8000cd0)at/MySQL/MySQL-5.7.17/sql/rpl_slave.cc:4102

其计算方式基本就是这段代码

time_diff= ((long)(time(0) - mi->rli->last_master_timestamp) - mi->clock_diff_with_master);

稍微解释一下：

time(0) ：取当前slave服务器系统时间。

mi->rli->last_master_timestamp：是event common header中timestamp的时间+exetime，其中exetime只有query event才有，其他全部是0,这也导致了binlog row格式下的延迟最大基本是(2 乘以主库的执行的时间)，但是DDL的语句包含在query event中索引延迟最大基本就是(1 乘以 主库执行时间)

mi->clock_diff_with_master：这是从库和主库时间的差值。

这里我们也看到event中common header中的timestamp和slave本地时间起了决定因素。因为每次发起命令time(0)都会增加，所以即便event中common header中的timestamp的时间不变延迟也是不断加大的。

另外还有一段有名的伪代码如下：

/*

The pseudo code to compute Seconds_Behind_Master:

if (SQL thread is running)

{

if (SQL thread processed all the available relay log)

{

if (IO thre