标签：表示   body   结果   不包含   header   方式   读取   delete   恢复   

本系列博客主要介绍MySQL数据库的binlog日志的相关内容，这个系列的主题包括：

MySQLbinlog日志01binlog日志基本操作

MySQLbinlog日志02binlog日志用于数据恢复

MySQLbinlog日志03binlog日志字节码解析

MySQLbinlog日志04binlog日志字节码解析之二Write_Rows事件

前一篇博客介绍了 

MySQLbinlog日志03binlog日志字节码解析

本篇博客将接着介绍Write Rows事件的字节码解析。

7.Write rows事件

现在来解析insert语句对应的核心binlog事件：Write rows事件。这个事件用于insert/update语句产生的增加和修改行数据的记录。每个Write rows事件只涉及对一行数据的增加或者修改，尽管这个事件的名字用了复数形式。

对应的字节码数据如下所示：

common header的内容如下：

时间戳：

Write rows事件的事件相关头结构格式还是从源代码注释中找到的，总体结构如下：

各个条目细分后的具体含义如下：

Write rows事件自身的字节码数据如下：

表id占6个字节，值为120。

标志占2个字节，值为1。

var_header_len占2个字节，值为2字节。包含了自身的长度以及附加行数据的长度。因此这个事件中没有附加行数据。

接着是列的个数，这个整数的编码规则比较复杂。下面这个代码用于读取这样的列的个数的字节码。具体代码如下所示：

这个事件中第1个字节为06，因此列的数量就是6个列，仅仅占用1个字节。

接着是操作前的行记录用到的列的标志。对于INSERT语句而言，不包含这一部分。对于UPDATE/DELETE而言，就是mysqlbinlog输出的WHERE中用到哪些列。因此具体格式在操作后的部分进行描述。

接着是操作后的行记录用到的列的标志。长度是(6+7)/8=1个字节，值为ff，只有6个二进制位有效。可以看到这个6个字段都被使用到了。这1个字节仅仅是标志位，不是实际的列数据。对于INSERT语句而言，就是新增的记录数据中包含哪些列。对于UPDATE而言，就是SET中用到哪些列。

最后是真正的行记录的列数据。因为在common header中已经知道了整个事件的长度，而此时前面这些部分的长度也已经确定了，那么列数据的长度也可以计算出来。实际上就是分析到此时的偏移量开始，到事件结束位置的前1字节为止的这个范围内的字节码。

列数据具体是怎么存储的，稍后介绍。

行数据先经过pack_row()函数进行组装后才写入到binlog文件中。pack_row()函数的代码经过精简后如下所示：

先存储NULL标记，即值为NULL的列标记，每个列用一个位来表示其后的值是否为NULL。

t1表只有6个列，因此这里值为NULL的列只可能占用1个字节。当前事件中这个值为0xc0。

最后6位全部是0，这6个列当前的值全部不为NULL。

接着依次存储每个值不是NULL的列的具体数据。

每一种类型的列都有对应的pack()函数。前面已经知道了t1表的6个列中，第2列（name）是varchar之外，其它列都是int。int类型的列在MySQL源代码中定义为Field_long类。

功能主要就是这个32位整数存储为Big endian格式的字节码，占用4个字节。

varchar类型的列对应的类是Field_varstring。

对于varstring，先存储字符串的长度，再存储实际的字符串。整数类型的列的存储方式和前面介绍的各种长度的存储方式是类似的，都可以认为是big-endian格式，而这里的字符串长度，是按照little-endian格式存储的。小于255字节，存储为1个字节，否则存储为2个字节。

现在来解析这个Write rows事件中包含的列的值，即行记录的具体数据。

这个结果与使用mysqlbinlog提取的结果是一致的：

最后面4个字节是这个binlog事件的校验码。

至此，INSERT语句对应的Write row事件的字节码解析完毕。UPDATE和DELETE语句对应的binlog事件的字节码解析方式跟这个非常类似，就不再赘述了。

 MySQL数据库binlog系列博客就是这些内容了。

MySQLbinlog日志04binlog日志字节码解析之二Write_Rows事件

标签：表示   body   结果   不包含   header   方式   读取   delete   恢复   

原文地址：https://www.cnblogs.com/coe2coe/p/9690708.html