MySQL：从库出现system lock的原因

 

导读：

作者：高鹏（网名八怪），《深入理解MySQL主从原理32讲》系列文的作者。

想阅读八怪源码文章欢迎订阅

---

本文建议横屏观看，效果更佳

水平有限有误请谅解。

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

• 本文基于5.7.17源码

• 本文只考虑row格式binlog

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

• 以单sql线程为例（非MTS）

如果要系统的学习主从原理可以参考我的 《深入理解MySQL主从原理 32讲》。

一、延迟的计算方式

其实每次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 in show_slave_status (thd=0x7fffd8000cd0) at /MySQL/MySQL-5.7.17/sql/rpl_slave.cc:3982
#2  0x0000000001867bfa in show_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中的timestam