原创：转载请说明出处谢谢！
上接
http://blog.itpub.net/7728585/viewspace-2133188/ 解析MYSQL BINLOG 二进制格式(1)--准备工作
http://blog.itpub.net/7728585/viewspace-2133189/ 解析MYSQL BINLOG 二进制格式(2)--FORMAT_DESCRIPTION_EVENT
http://blog.itpub.net/7728585/viewspace-2133321/ 解析MYSQL BINLOG 二进制格式(3)--QUERY_EVENT
http://blog.itpub.net/7728585/viewspace-2133429/ 解析MYSQL BINLOG 二进制格式(4)--TABLE_MAP_EVENT
http://blog.itpub.net/7728585/viewspace-2133463/ 解析MYSQL BINLOG 二进制格式(5)--WRITE_ROW_EVENT
class:Update_rows_log_event
event:UPDATE_ROW_EVENT
event_code:31
class:Delele_rows_log_event
event:DELETE_ROW_EVENT
event_code:32
自从5.1.18开始,row模式下的update/delete的event
这部分将UPDATE_ROW_EVENT和DELETE_ROWS_EVENT放到一起因为了有了前面WRITE_ROW_EVENT 的
基础这两个基本和他一致，只是要注意UPDATE_ROW_EVENT存放了前后印象
--fixed data 10字节(5.6,5.7中描述为 ROWS_HEADER_LEN_V2)
6 bytes 表ID
2 bytes 保留
2 bytes 文档中并没有描述
源码中描述为：
uchar *m_extra_row_data; /* Pointer to extra row data if any */
/* If non null, first byte is length */
具体参考前面一篇(解析MYSQL BINLOG 二进制格式(5)--WRITE_ROW_EVENT)
--variable data part
packed integer：表中字段个数，这个地方为packed integer自行参考源码
uchar *net_store_length或者参考第一章
(解析MYSQL BINLOG 二进制格式(1)--准备工作 )
var-size:文档解释为每一位代表是否字段用到了 长度为INT((n+7)/8) n代表字段数量
源码描述为 m_cols; /* Bitmap denoting columns available */
测试表现这一字节和binlog_row_image设置有关，默认为FULL每一个字节始终为
0XFF
var-size-update:UPDATE_ROW_EVENT专用和前面描述的一致，但是表示的是后印象，也就是update后的数据
var-size:每一位代表的字段的值是否为NULL，长度为INT((n+7)/8) n代表字段数量，
他采用一个位图的方式。
1：NULL
0：NOT NULL
var-size:这部分就是真正的数据了。
var-size-update:
var-size-update:
这两部分为UPDATE_ROW_EVENT专用和前面描述的两部分一致，但是表示的是后印象，也就是update后的数据
接下来进行实际的解析：
执行语句
mysql> select * from testnull2;
+------+-------+-------+
| id | name1 | name2 |
+------+-------+-------+
| NULL | test | NULL |
+------+-------+-------+
1 row in set (0.01 sec)
mysql> update testnull2 set id=2,name2='test',name1=NULL where name1='test';
Query OK, 1 row affected (0.01 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> delete from testnull2;
Query OK, 1 row affected (0.02 sec)
使用./infobin (自己开发 我放到了云盘)
http://pan.baidu.com/s/1jHIWUN0
[root@testmy data]# ./infobin test.000184
Check is Little_endian
Author: gaopeng QQ:22389860 Mail: gaopp_200217@163.com
Waring: This tool only Little_endian platform!
Little_endian check ok!!!
-------------Now begin--------------
Check Mysql Version is:5.7.13-log
Check Mysql binlog format ver is:V4
------------Detail now--------------
>Gtid Event:Pos:194(0Xc2) N_pos:259(0X103) Time:1486949924 Event_size:65(bytes)
Gtid:4a6f2a67-5d87-11e6-a6bd-0c29a879a3:1000450
-->Query Event:Pos:259(0X103) N_Pos:331(0X14b) Time:1486949924 Event_size:72(bytes)
Exe_time:0 Use_db:test Statment(35b-trun):BEGIN
---->Map Event:Pos331(0X14b) N_pos:389(0X185) Time:1486949924 Event_size:58(bytes)
TABLE_ID:210 DB_NAME:test TABLE_NAME:testnull2
------>Update Event:Pos:389(0X185) N_pos is:441(0X1b9) time:1486949924 event_size:52(bytes)
Dml on table: test.testnull2 table_id:210 Gno:1000450
>Xid Event:Pos:441(0X1b9) N_Pos:472(0X1d8) Time:1486949924 Event_size:31(bytes)
COMMIT 1000450 /*!add by tool*/
>Gtid Event:Pos:472(0X1d8) N_pos:537(0X219) Time:1486949930 Event_size:65(bytes)
Gtid:4a6f2a67-5d87-11e6-a6bd-0c29a879a3:1000451
-->Query Event:Pos:537(0X219) N_Pos:609(0X261) Time:1486949930 Event_size:72(bytes)
Exe_time:0 Use_db:test Statment(35b-trun):BEGIN
---->Map Event:Pos609(0X261) N_pos:667(0X29b) Time:1486949930 Event_size:58(bytes)
TABLE_ID:210 DB_NAME:test TABLE_NAME:testnull2
------>Delete Event:Pos:667(0X29b) N_pos:712(0X2c8) Time:1486949930 Event_size:45(bytes)
Dml on table: test.testnull2 table_id:210 Gno:1000451
>Xid Event:Pos:712(0X2c8) N_Pos:743(0X2e7) Time:1486949930 Event_size:31(bytes)
COMMIT 1000451 /*!add by tool*/
可以看到我们的update和delete的位置
------>Update Event:Pos:389(0X185) N_pos is:441(0X1b9) time:1486949924 event_size:52(bytes)
Dml on table: test.testnull2 table_id:210 Gno:1000450
------>Delete Event:Pos:667(0X29b) N_pos:712(0X2c8) Time:1486949930 Event_size:45(bytes)
Dml on table: test.testnull2 table_id:210 Gno:1000451
现在使用mysqlbinlog --hexdump -vv 进行解析
先来看update event
二进制解析
# at 389
#170213 9:38:44 server id 93157 end_log_pos 441 CRC32 0x21c0591d
# Position Timestamp Type Master ID Size Master Pos Flags
# 185 24 0e a1 58 1f e5 6b 01 00 34 00 00 00 b9 01 00 00 00 00
# 198 d2 00 00 00 00 00 01 00 02 00 03 ff ff fd 04 74 |...............t|
# 1a8 65 73 74 fa 02 00 00 00 04 74 65 73 74 1d 59 c0 |est......test.Y.|
# 1b8 21 |.|
# Update_rows: table id 210 flags: STMT_END_F
-vv输出
### UPDATE `test`.`testnull2`
### WHERE
### @1=NULL /* type=3 meta=0 nullable=1 is_null=1 */
### @2='test' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */
### @3=NULL /* VARSTRING(60) meta=60 nullable=1 is_null=1 */
### SET
### @1=2 /* INT meta=0 nullable=1 is_null=0 */
### @2=NULL /* INT meta=60 nullable=1 is_null=1 */
### @3='test' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */
分解：
--event header 部分就不解析了table id 210，
--hexdump也明确的解析了，不理解参考前面的文章
# Position Timestamp Type Master ID Size Master Pos Flags
# 185 24 0e a1 58 1f e5 6b 01 00 34 00 00 00 b9 01 00 00 00 00
--fixed data
d2 00 00 00 00 00：表ID就是./infobin中的TABLE_ID:210 也是mysqlbinlog中的Update_rows: table id 210
小端显示
01 00：保留
02 00：m_extra_row_data,这部分是我看源码找到的。
--variable data part
03：表中字段个数，当然我建表就是3个字段
ff: 源码描述为 m_cols; /* Bitmap denoting columns available */
ff：update专用和上面一致
----update前印象数据：
fd: 11111101 代表字段@1=NULL和@3=NULL，但是字段@2不为空这和mysqlbinlog解析的一致
@1=NULL /* type=3 meta=0 nullable=1 is_null=1 */
@2='test' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */
@3=NULL /* VARSTRING(60) meta=60 nullable=1 is_null=1 */
04:var 长度04 就是数据'test'的长度为4，这个也就是@2='test'事update的前印象
74 65 73 74：字符串'test'
----update后印象数据(update 专用)：
fa：11111010，@2=NULL，但是修改后@1和@3不为空和mysqlbinlog解析一致
@1=2 /* INT meta=0 nullable=1 is_null=0 */
@2=NULL /* INT meta=60 nullable=1 is_null=1 */
@3='test' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */
02 00 00 00 ：也就是数据2也是@1=2也就是update的后印象，小端显示
04： var 长度04 就是数据'test'的长度为4，也就是
74 65 73 74：字符串'test'也是@3='test'也就是update的后印象
1d 59 c0 21：CRC32校验
然后来看delete event
二进制解析
# at 667
#170213 9:38:50 server id 93157 end_log_pos 712 CRC32 0x055741c1
# Position Timestamp Type Master ID Size Master Pos Flags
# 29b 2a 0e a1 58 20 e5 6b 01 00 2d 00 00 00 c8 02 00 00 00 00
# 2ae d2 00 00 00 00 00 01 00 02 00 03 ff fa 02 00 00 |................|
# 2be 00 04 74 65 73 74 c1 41 57 05 |..test.AW.|
# Delete_rows: table id 210 flags: STMT_END_F
-vv输出
### DELETE FROM `test`.`testnull2`
### WHERE
### @1=2 /* INT meta=0 nullable=1 is_null=0 */
### @2=NULL /* INT meta=60 nullable=1 is_null=1 */
### @3='test' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */
分解：
--event header 部分就不解析了table id 210，
--hexdump也明确的解析了，不理解参考前面的文章
# Position Timestamp Type Master ID Size Master Pos Flags
# 185 24 0e a1 58 1f e5 6b 01 00 34 00 00 00 b9 01 00 00 00 00
--fixed data
d2 00 00 00 00 00：表ID就是./infobin中的TABLE_ID:210 也是mysqlbinlog中的Delete_rows: table id 210
小端显示
01 00：保留
02 00：m_extra_row_data,这部分是我看源码找到的。
--variable data part
03：表中字段个数，当然我建表就是3个字段
ff: 源码描述为 m_cols; /* Bitmap denoting columns available */
fa: 11111010 代表字段@2=NULL，但是字段@1 @3不为空这和mysqlbinlog解析的一致
@1=2 /* INT meta=0 nullable=1 is_null=0 */
@2=NULL /* INT meta=60 nullable=1 is_null=1 */
@3='test' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */
02 00 00 00: int 4字节数据 2及@1=2 小端显示
04:var 长度04 就是数据'test'的长度为4，这个也就是@3='test'
74 65 73 74：字符串'test'
c1 41 57 05：crc32 校验
至此UPDATE_ROW_EVENT和DELETE_ROWS_EVENT解析完毕
后记：
1、在UPDATE_ROW_EVENT/DELETE_ROWS_EVENT/WRITE_ROWS_EVENT中存在一个字段值是否为空的位图，如前面所说
然后紧跟了字段数据，这样根据位图就能确定出那些字段为NULL，而实际存储的值中并不包含NULL字段的数据
因为它没有数据，同样也为了减少存储空间的使用，这种技术在数据库技术中大量使用，在INNODB PAGES中也
是用到了。
2、很多闪回工具都依赖了binlog中能够记录了需要的所有信息，我们也看到了update还记录前后印象的值，那么
也为闪回提供了条件，但是binlog_row_image会影响它的记录方式具体参考官方手册，但是它可以节约空间。
上接
http://blog.itpub.net/7728585/viewspace-2133188/ 解析MYSQL BINLOG 二进制格式(1)--准备工作
http://blog.itpub.net/7728585/viewspace-2133189/ 解析MYSQL BINLOG 二进制格式(2)--FORMAT_DESCRIPTION_EVENT
http://blog.itpub.net/7728585/viewspace-2133321/ 解析MYSQL BINLOG 二进制格式(3)--QUERY_EVENT
http://blog.itpub.net/7728585/viewspace-2133429/ 解析MYSQL BINLOG 二进制格式(4)--TABLE_MAP_EVENT
http://blog.itpub.net/7728585/viewspace-2133463/ 解析MYSQL BINLOG 二进制格式(5)--WRITE_ROW_EVENT
class:Update_rows_log_event
event:UPDATE_ROW_EVENT
event_code:31
class:Delele_rows_log_event
event:DELETE_ROW_EVENT
event_code:32
自从5.1.18开始,row模式下的update/delete的event
这部分将UPDATE_ROW_EVENT和DELETE_ROWS_EVENT放到一起因为了有了前面WRITE_ROW_EVENT 的
基础这两个基本和他一致，只是要注意UPDATE_ROW_EVENT存放了前后印象
--fixed data 10字节(5.6,5.7中描述为 ROWS_HEADER_LEN_V2)
6 bytes 表ID
2 bytes 保留
2 bytes 文档中并没有描述
源码中描述为：
uchar *m_extra_row_data; /* Pointer to extra row data if any */
/* If non null, first byte is length */
具体参考前面一篇(解析MYSQL BINLOG 二进制格式(5)--WRITE_ROW_EVENT)
--variable data part
packed integer：表中字段个数，这个地方为packed integer自行参考源码
uchar *net_store_length或者参考第一章
(解析MYSQL BINLOG 二进制格式(1)--准备工作 )
var-size:文档解释为每一位代表是否字段用到了 长度为INT((n+7)/8) n代表字段数量
源码描述为 m_cols; /* Bitmap denoting columns available */
测试表现这一字节和binlog_row_image设置有关，默认为FULL每一个字节始终为
0XFF
var-size-update:UPDATE_ROW_EVENT专用和前面描述的一致，但是表示的是后印象，也就是update后的数据
var-size:每一位代表的字段的值是否为NULL，长度为INT((n+7)/8) n代表字段数量，
他采用一个位图的方式。
1：NULL
0：NOT NULL
var-size:这部分就是真正的数据了。
var-size-update:
var-size-update:
这两部分为UPDATE_ROW_EVENT专用和前面描述的两部分一致，但是表示的是后印象，也就是update后的数据
接下来进行实际的解析：
执行语句
mysql> select * from testnull2;
+------+-------+-------+
| id | name1 | name2 |
+------+-------+-------+
| NULL | test | NULL |
+------+-------+-------+
1 row in set (0.01 sec)
mysql> update testnull2 set id=2,name2='test',name1=NULL where name1='test';
Query OK, 1 row affected (0.01 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> delete from testnull2;
Query OK, 1 row affected (0.02 sec)
使用./infobin (自己开发 我放到了云盘)
http://pan.baidu.com/s/1jHIWUN0
[root@testmy data]# ./infobin test.000184
Check is Little_endian
Author: gaopeng QQ:22389860 Mail: gaopp_200217@163.com
Waring: This tool only Little_endian platform!
Little_endian check ok!!!
-------------Now begin--------------
Check Mysql Version is:5.7.13-log
Check Mysql binlog format ver is:V4
------------Detail now--------------
>Gtid Event:Pos:194(0Xc2) N_pos:259(0X103) Time:1486949924 Event_size:65(bytes)
Gtid:4a6f2a67-5d87-11e6-a6bd-0c29a879a3:1000450
-->Query Event:Pos:259(0X103) N_Pos:331(0X14b) Time:1486949924 Event_size:72(bytes)
Exe_time:0 Use_db:test Statment(35b-trun):BEGIN
---->Map Event:Pos331(0X14b) N_pos:389(0X185) Time:1486949924 Event_size:58(bytes)
TABLE_ID:210 DB_NAME:test TABLE_NAME:testnull2
------>Update Event:Pos:389(0X185) N_pos is:441(0X1b9) time:1486949924 event_size:52(bytes)
Dml on table: test.testnull2 table_id:210 Gno:1000450
>Xid Event:Pos:441(0X1b9) N_Pos:472(0X1d8) Time:1486949924 Event_size:31(bytes)
COMMIT 1000450 /*!add by tool*/
>Gtid Event:Pos:472(0X1d8) N_pos:537(0X219) Time:1486949930 Event_size:65(bytes)
Gtid:4a6f2a67-5d87-11e6-a6bd-0c29a879a3:1000451
-->Query Event:Pos:537(0X219) N_Pos:609(0X261) Time:1486949930 Event_size:72(bytes)
Exe_time:0 Use_db:test Statment(35b-trun):BEGIN
---->Map Event:Pos609(0X261) N_pos:667(0X29b) Time:1486949930 Event_size:58(bytes)
TABLE_ID:210 DB_NAME:test TABLE_NAME:testnull2
------>Delete Event:Pos:667(0X29b) N_pos:712(0X2c8) Time:1486949930 Event_size:45(bytes)
Dml on table: test.testnull2 table_id:210 Gno:1000451
>Xid Event:Pos:712(0X2c8) N_Pos:743(0X2e7) Time:1486949930 Event_size:31(bytes)
COMMIT 1000451 /*!add by tool*/
可以看到我们的update和delete的位置
------>Update Event:Pos:389(0X185) N_pos is:441(0X1b9) time:1486949924 event_size:52(bytes)
Dml on table: test.testnull2 table_id:210 Gno:1000450
------>Delete Event:Pos:667(0X29b) N_pos:712(0X2c8) Time:1486949930 Event_size:45(bytes)
Dml on table: test.testnull2 table_id:210 Gno:1000451
现在使用mysqlbinlog --hexdump -vv 进行解析
先来看update event
二进制解析
# at 389
#170213 9:38:44 server id 93157 end_log_pos 441 CRC32 0x21c0591d
# Position Timestamp Type Master ID Size Master Pos Flags
# 185 24 0e a1 58 1f e5 6b 01 00 34 00 00 00 b9 01 00 00 00 00
# 198 d2 00 00 00 00 00 01 00 02 00 03 ff ff fd 04 74 |...............t|
# 1a8 65 73 74 fa 02 00 00 00 04 74 65 73 74 1d 59 c0 |est......test.Y.|
# 1b8 21 |.|
# Update_rows: table id 210 flags: STMT_END_F
-vv输出
### UPDATE `test`.`testnull2`
### WHERE
### @1=NULL /* type=3 meta=0 nullable=1 is_null=1 */
### @2='test' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */
### @3=NULL /* VARSTRING(60) meta=60 nullable=1 is_null=1 */
### SET
### @1=2 /* INT meta=0 nullable=1 is_null=0 */
### @2=NULL /* INT meta=60 nullable=1 is_null=1 */
### @3='test' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */
分解：
--event header 部分就不解析了table id 210，
--hexdump也明确的解析了，不理解参考前面的文章
# Position Timestamp Type Master ID Size Master Pos Flags
# 185 24 0e a1 58 1f e5 6b 01 00 34 00 00 00 b9 01 00 00 00 00
--fixed data
d2 00 00 00 00 00：表ID就是./infobin中的TABLE_ID:210 也是mysqlbinlog中的Update_rows: table id 210
小端显示
01 00：保留
02 00：m_extra_row_data,这部分是我看源码找到的。
--variable data part
03：表中字段个数，当然我建表就是3个字段
ff: 源码描述为 m_cols; /* Bitmap denoting columns available */
ff：update专用和上面一致
----update前印象数据：
fd: 11111101 代表字段@1=NULL和@3=NULL，但是字段@2不为空这和mysqlbinlog解析的一致
@1=NULL /* type=3 meta=0 nullable=1 is_null=1 */
@2='test' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */
@3=NULL /* VARSTRING(60) meta=60 nullable=1 is_null=1 */
04:var 长度04 就是数据'test'的长度为4，这个也就是@2='test'事update的前印象
74 65 73 74：字符串'test'
----update后印象数据(update 专用)：
fa：11111010，@2=NULL，但是修改后@1和@3不为空和mysqlbinlog解析一致
@1=2 /* INT meta=0 nullable=1 is_null=0 */
@2=NULL /* INT meta=60 nullable=1 is_null=1 */
@3='test' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */
02 00 00 00 ：也就是数据2也是@1=2也就是update的后印象，小端显示
04： var 长度04 就是数据'test'的长度为4，也就是
74 65 73 74：字符串'test'也是@3='test'也就是update的后印象
1d 59 c0 21：CRC32校验
然后来看delete event
二进制解析
# at 667
#170213 9:38:50 server id 93157 end_log_pos 712 CRC32 0x055741c1
# Position Timestamp Type Master ID Size Master Pos Flags
# 29b 2a 0e a1 58 20 e5 6b 01 00 2d 00 00 00 c8 02 00 00 00 00
# 2ae d2 00 00 00 00 00 01 00 02 00 03 ff fa 02 00 00 |................|
# 2be 00 04 74 65 73 74 c1 41 57 05 |..test.AW.|
# Delete_rows: table id 210 flags: STMT_END_F
-vv输出
### DELETE FROM `test`.`testnull2`
### WHERE
### @1=2 /* INT meta=0 nullable=1 is_null=0 */
### @2=NULL /* INT meta=60 nullable=1 is_null=1 */
### @3='test' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */
分解：
--event header 部分就不解析了table id 210，
--hexdump也明确的解析了，不理解参考前面的文章
# Position Timestamp Type Master ID Size Master Pos Flags
# 185 24 0e a1 58 1f e5 6b 01 00 34 00 00 00 b9 01 00 00 00 00
--fixed data
d2 00 00 00 00 00：表ID就是./infobin中的TABLE_ID:210 也是mysqlbinlog中的Delete_rows: table id 210
小端显示
01 00：保留
02 00：m_extra_row_data,这部分是我看源码找到的。
--variable data part
03：表中字段个数，当然我建表就是3个字段
ff: 源码描述为 m_cols; /* Bitmap denoting columns available */
fa: 11111010 代表字段@2=NULL，但是字段@1 @3不为空这和mysqlbinlog解析的一致
@1=2 /* INT meta=0 nullable=1 is_null=0 */
@2=NULL /* INT meta=60 nullable=1 is_null=1 */
@3='test' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */
02 00 00 00: int 4字节数据 2及@1=2 小端显示
04:var 长度04 就是数据'test'的长度为4，这个也就是@3='test'
74 65 73 74：字符串'test'
c1 41 57 05：crc32 校验
至此UPDATE_ROW_EVENT和DELETE_ROWS_EVENT解析完毕
后记：
1、在UPDATE_ROW_EVENT/DELETE_ROWS_EVENT/WRITE_ROWS_EVENT中存在一个字段值是否为空的位图，如前面所说
然后紧跟了字段数据，这样根据位图就能确定出那些字段为NULL，而实际存储的值中并不包含NULL字段的数据
因为它没有数据，同样也为了减少存储空间的使用，这种技术在数据库技术中大量使用，在INNODB PAGES中也
是用到了。
2、很多闪回工具都依赖了binlog中能够记录了需要的所有信息，我们也看到了update还记录前后印象的值，那么
也为闪回提供了条件，但是binlog_row_image会影响它的记录方式具体参考官方手册，但是它可以节约空间。
