​MySQL 一个让你怀疑人生的hang死现象

然后，查看了当前正在运行的线程状态信息，发现一个sleep长达157269S的线程，这是什么鬼。。大事务未提交吗？窃喜！接着，我们查看了事务和锁信息再接着，我们查看了一下系统负载，内存、网络、磁盘都几乎无负载，CPU也没啥负载，但却有一个奇怪的现象，有一个CPU核心的利用率为100%，如下最后，在恢复库中，我们查看了一下GTID信息，发现GTID号不连续，少了一个事务的GTID（3759）通过查看从库中的GTID（也就是恢复库的数据源对应的库），并没有少GTID号开发云主机域名为3759的事务，为什么莫名在恢复库中会少，而不是连续的？带着好奇，我们使用该GTID号解析了从库中的所有被指定用于恢复的binlog file列表（这里指的就是mysql-bin.000014 mysql-bin.000015 mysql-bin.000016 mysql-bin.000017 mysql-bin.000018 mysql-bin.000019），从这些binlog中提取了GTID号为3759的事务的binlog日志内容使用strace工具查看登录MySQL并加载binlog解析文本过程中的一些输出信息（这里直接使用上文中提到的b.sql）现在，另起一个终端会话，查看strace.txt文件中的内容注意：如果你在跟随我们的复现过程玩耍，建议你查看一下show processlist的信息，你可能会发现之前导入b.sql文件的客户端连接在数据库中并没有被断开，如果发现此情况，则需要在数据库中手工执行kill操作登录到MySQL并执行导入b.sql文件操作（不要用strace）使用pstack工具查看MySQL客户端连接的进程堆栈信息由于是在MySQL 5.7.26版本中发生的故障，所以我们首先查看了MySQL 5.7.26版本的客户端源码，MySQL客户端在读取一个文件时（或者说判断什么时候可以将一个操作发送给服务端时），碰到’;’分号会直接将前面读取到的内容作为一整个数据包丢给服务端，对上文中提到的b.sql文件中的BINLOG编码，整个BINLOG编码只有一个分号，所以会等到整个BINLOG编码读取完成之后才会发送给服务端，在读取这个超大BINLOG编码的过程中，MySQL客户端会一行一行的读，并记录到global_buffer中。当global_buffer申请的空间不足时，就需要扩展内存空间，，扩展内存空间的代码如下：接下来，我们解决第二个问题，比对MySQL 5.7.26和MySQL 8.0.16版本中，关于客户端缓存读取文件数据这块的内存分配代码有什么不同？最后，多说一句，MariaDB虽然也同样解决了这个问题，但是解决方法完全不同（粗略看了一下代码，没细看），通过比对解析的BINLOG编码，发现MariaDB的BINLOG编码是存在一个个的空缺，所以猜测可能是采用了”mysqlbinlog的解析格式变更”配合”mysql客户端的解析逻辑变更”来解决该问题的（MariaDB在执行导入binlog解析内容时，show processlist查看线程状态也能发现导入数据的线程一直在干活，并不是一直处于Sleep状态），类似如下MariaDB

* BINLOG编码格式

* show processlist状态

MySQL* BINLOG编码格式
* show processlist状态

| 作者简介

罗小波沃趣科技高级数据库技术专家
IT从业多年，主要负责MySQL 产品的数据库支撑与售后二线支撑。曾参与版本发布系统、轻量级监控系统、运维管理平台、数据库管理平台的设计与编写，熟悉MySQL体系结构，Innodb存储引擎，喜好专研开源技术，多次在公开场合做过线下线上数据库专题分享，发表过多篇数据库相关的研究文章。

相关推荐: 怎样在磁盘上查找MySQL表的大小？这里有答案

我想知道 MySQL 表在磁盘上占用多少空间，但看起来很琐碎。不应该在 INFORMATION_SCHEMA.TABLES 中提供这些信息吗?没那么简单! 这个看似简单的问题实际上在 MySQL 中非常复杂。MySQL 支持许多存储引擎(其中一些根本不在磁盘上…