MySQL：从库出现system lock的原因

最新推荐文章于 2022-05-10 22:40:01 发布

老叶茶馆_

最新推荐文章于 2022-05-10 22:40:01 发布

阅读量6.9k

点赞数

本文链接：https://blog.csdn.net/n88Lpo/article/details/103775602

版权

本文探讨了MySQL从库出现system lock状态的原因，分析了延迟的计算方式、binlog写入与event生成时间，并列举了可能导致延迟的原因，如大事物、大表DDL、未提交事务、无主键表及InnoDB锁。通过分析得出，system lock并不表示真正的锁定，而是从库在执行DML操作的状态。建议检查表是否有主键、调整参数以及关注小事物对大表的影响。

摘要由CSDN通过智能技术生成

导读：

作者：高鹏（网名八怪），《深入理解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中com