如果图片不能显示可查看下面链接：
https://www.jianshu.com/p/d636215d767f

有了前面对Event的了解，我们就可以利用这些Event来完成一些工作了。我曾经在学习了这些常用的Event后，使用C语言写过一个解析Event的工具，我叫它‘infobin’，意思就是从binary log提取信息的意思。据我所知虽然这个工具在少数情况下会出现BUG但是还是有些朋友在用。我这里并不是要推广我的工具，而是要告诉大家这种思路。我是结合工作中遇到的一些问题来完成了这个工具的，主要功能包含如下：

分析binary log中是否有长期未提交的事务 ，长期不提交的事务将会引发更多的锁争用。

分析binary log中是否有大事务 ，大事务的提交可能会堵塞其它事务的提交。

分析binary log中每个表生成了多少DML Event，这样就能知道哪个表的修改量最大。

分析binary log中Event的生成速度，这样就能知道哪个时间段生成的Event更多。

这个工具的帮助信息如下：

[root@gp1infobin]#./infobinUSAGEERROR![Author]:gaopeng[QQ]:22389860[blog]:http://blog.itpub.net/7728585/--USAGE:./infobinbinlogfilepiecesbigtrxsizebigtrxtime[-t][-force][binlogfile]:binlogfile![piece]:howmanypiecewillsplit,isaHighlybalancedhistogram,findwhichtimegeneratebiggestbinlog.(must:piece<2000000)[bigtrxsize](bytes):largerthanthissizetrxwillview.(must:trx>256(bytes))[bigtrxtime](sec):largerthanthissectrxwillview.(must:>0(sec))[[-t]]:if[-t]nodetailisprintout,theresultwillsmall[[-force]]:forceanalyzeifunkownerrorcheck!!

接下来我们具体来看看这几个功能大概是怎么实现的。

一、分析长期未提交的事务

前面我已经多次提到过对于一个手动提交的事务而言有如下特点，我们以‘Insert’语句为列：

GTID_LOG_EVENT和XID_EVENT是命令‘COMMIT’发起的时间。

QUERY_EVENT是第一个‘Insert’命令发起的时间。

MAP_EVENT/WRITE_ROWS_EVENT是每个‘Insert’命令发起的时间。

那实际上我们就可以用（1）减去（2）就能得到第一个‘DML’命令发起到‘COMMIT’命令发起之间所消耗的时间，再使用一个用户输入参数来自定义多久没有提交的事务叫做长期未提交的事务就可以了，我的工具中使用bigtrxtime作为这个输入。我们来用一个例子说明，我们做如下语句：

语句时间beginT1insert into testrr values(20);11:25:22insert into testrr values(30);11:25:26insert into testrr values(40);11:25:28commit;11:25:30

我们来看看Event的顺序和时间如下：
|Event|时间|
|—-|—-|
|GTID_LOG_EVENT|11:25:30|
|QUERY_EVENT|11:25:22|
|MAP_EVENT（第1个insert）|11:25:22|
|WRITE_ROWS_EVENT（第1个insert）|11:25:22|
|MAP_EVENT（第2个insert）|11:25:26|
|WRITE_ROWS_EVENT（第2个insert）|11:25:26|
|MAP_EVENT（第3个insert）|11:25:28|
|WRITE_ROWS_EVENT（第3个insert）|11:25:28|
|XID_EVENT|11:25:30|

如果我们使用最后一个XID_EVENT的时间减去QUERY_EVENT的时间，那么这个事务从第一条语句开始到‘COMMIT’的时间就计算出来了。注意一点，实际上‘BEGIN’命令并没有记录到Event中，它只是做了一个标记让事务不会自动进入提交流程，关于‘BEGIN’命令做了什么可以参考我的简书文章如下：
https://www.jianshu.com/p/6de1e8071279

二、分析大事务

这部分实现比较简单，我们只需要扫描每一个事务GTID_LOG_EVENT和XID_EVENT之间的所有Event将它们的总和计算下来，就可以得到每一个事务生成Event的大小（但是为了兼容最好计算QUERY_EVENT和XID_EVENT之间的Event总量）。再使用一个用户输入参数自定义多大的事务叫做大事务就可以了，我的工具中使用bigtrxsize作为这个输入参数。

如果参数binlog_row_image参数设置为‘FULL’，我们可以大概计算一下特定表的每行数据修改生成的日志占用的大小：

‘Insert’和‘Delete’：因为只有before_image或者after_image，因此100字节一行数据加上一些额外的开销大约加上10字节也就是110字节一行。如果定位大事务为100M那么大约修改量为100W行数据。

‘Update’：因为包含before_image和after_image，因此上面的计算的110字节还需要乘以2。因此如果定位大事务为100M那么大约修改量为50W行数据。

我认为20M作为大事务的定义比较合适，当然这个根据自己的需求进行计算。

三、分析binary log中Event的生成速度

这个实现就很简单了，我们只需要把binary log按照输入参数进行分片，统计结束Event和开始Event的时间差值就能大概算出每个分片生成花费了多久时间，我们工具使用piece作为分片的传入参数。通过这个分析，我们可以大概知道哪一段时间Event生成量更大，也侧面反映了数据库的繁忙程度。

四、分析每个表生成了多少DML Event

这个功能也非常实用，通过这个分析我们可以知道数据库中哪一个表的修改量最大。实现方式主要是通过扫描binary log中的MAP_EVENT和接下来的DML Event，通过table id获取表名，然后将DML Event的大小归入这个表中，做一个链表，最后排序输出就好了。但是前面我们说过table id即便在一个事务中也可能改变，这是我开始没有考虑到的，因此这个工具有一定的问题，但是大部分情况是可以正常运行的。

五、工具展示

下面我就来展示一下我说的这些功能，我做了如下操作：

mysql>flushbinarylogs;QueryOK,0rowsaffected(0.51sec)mysql>selectcount(*)fromtti;+----------+|count(*)|+----------+|98304|+----------+1rowinset(0.06sec)mysql>deletefromtti;QueryOK,98304rowsaffected(2.47sec)mysql>begin;QueryOK,0rowsaffected(0.00sec)mysql>insertintottivalues(1,'gaopeng');QueryOK,1rowaffected(0.00sec)mysql>selectsleep(20);+-----------+|sleep(20)|+-----------+|0|+-----------+1rowinset(20.03sec)mysql>commit;QueryOK,0rowsaffected(0.22sec)mysql>insertintotppvalues(10);QueryOK,1rowaffected(0.14sec)

在示例中我切换了一个binary log，同时做了3个事务：

删除了tti表数据一共98304行数据。

向tti表插入了一条数据，等待了20多秒提交。

向tpp表插入了一条数据。

我们使用工具来分析一下，下面是统计输出：

./infobinmysql-bin.0000053100000015-t>log.logmorelog.log...-------------Totalnow--------------Trxtotal[counts]:3Eventtotal[counts]:125Maxtrxeventsize:8207(bytes)Pos:420[0X1A4]Avgbinlogsize(/sec):9265.844(bytes)[9.049(kb)]Avgbinlogsize(/min):555950.625(bytes)[542.921(kb)]--Pieceview:(1)Time:1561442359-1561442383(24(s))piece:296507(bytes)[289.558(kb)](2)Time:1561442383-1561442383(0(s))piece:296507(bytes)[289.558(kb)](3)Time:1561442383-1561442455(72(s))piece:296507(bytes)[289.558(kb)]--Largethan500000(bytes)trx:(1)Trx_size:888703(bytes)[867.874(kb)]trx_begin_p:299[0X12B]trx_end_p:889002[0XD90AA]Totallargetrxcountsize(kb):#867.874(kb)--Largethan15(secs)trx:(1)Trx_sec:31(sec)trx_begin_time:[2019062514:00:08(CST)]trx_end_time:[2019062514:00:39(CST)]trx_begin_pos:889067trx_end_pos:889267query_exe_time:0--EveryTablebinlogsize(bytes)andtimes:Note:sizeunitisbytes---(1)CurrentTable:test.tpp::Insert:binlogsize(40(Bytes))times(1)Update:binlogsize(0(Bytes))times(0)Delete:binlogsize(0(Bytes))times(0)Total:binlogsize(40(Bytes))times(1)---(2)CurrentTable:test.tti::Insert:binlogsize(48(Bytes))times(1)Update:binlogsize(0(Bytes))times(0)Delete:binlogsize(888551(Bytes))times(109)Total:binlogsize(888599(Bytes))times(110)---Totalbinlogdmleventsize:888639(Bytes)times(111)

我们发现我们做的操作都统计出来了：

包含一个大事务日志总量大于500K，大小为800K左右，这是我的删除tti表中98304行数据造成的。

--Largethan500000(bytes)trx:(1)Trx_size:888703(bytes)[867.874(kb)]trx_begin_p:299[0X12B]trx_end_p:889002[0XD90AA]

包含一个长期未提交的事务，时间为31秒，这是我特意等待20多秒提交引起的。

--Largethan15(secs)trx:(1)Trx_sec:31(sec)trx_begin_time:[2019062514:00:08(CST)]trx_end_time:[2019062514:00:39(CST)]trx_begin_pos:889067trx_end_pos:889267query_exe_time:0

本binary log有两个表的修改记录tti和tpp，其中tti表有‘Delete’操作和‘Insert’操作，tpp表只有‘Insert’操作，并且包含了日志量的大小。

--EveryTablebinlogsize(bytes)andtimes:Note:sizeunitisbytes---(1)CurrentTable:test.tpp::Insert:binlogsize(40(Bytes))times(1)Update:binlogsize(0(Bytes))times(0)Delete:binlogsize(0(Bytes))times(0)Total:binlogsize(40(Bytes))times(1)---(2)CurrentTable:test.tti::Insert:binlogsize(48(Bytes))times(1)Update:binlogsize(0(Bytes))times(0)Delete:binlogsize(888551(Bytes))times(109)Total:binlogsize(888599(Bytes))times(110)---Totalbinlogdmleventsize:888639(Bytes)times(111)

好了到这里我想告诉你的就是，学习了Event过后就可以自己通过各种语言去试着解析binary log，也许你还能写出更好的工具实现更多的功能。

当然也可以通过mysqlbinlog 进行解析后，然后通过shell/python去统计，但是这个工具的速度要远远快于这种方式。