504到764为
# at 473
#170609 15:20:45 server id 933310 end_log_pos 504 CRC32 0x609296d7 Xid = 161
COMMIT/*!*/; ---注意这里上一个事物的结束叫做xid event
# at 504 ---这里是事物1 的起点没叫做gtid event
#170609 15:32:58 server id 933310 end_log_pos 569 CRC32 0xf7eebfc7 GTID [commit=yes]
SET @@SESSION.GTID_NEXT= '89dfa8a4-cb13-11e6-b504-000c29a879a3:2'/*!*/;
# at 569 ---这段event是query event
#170609 15:32:58 server id 933310 end_log_pos 641 CRC32 0xb4caa78c Query thread_id=4 exec_time=0 error_code=0
SET TIMESTAMP=1496993578/*!*/;
BEGIN
/*!*/;
# at 641 ---这段event是map event
#170609 15:32:58 server id 933310 end_log_pos 689 CRC32 0xb055655f Table_map: `test`.`test` mapped to number 142
# at 689 ---这段event是insert event
#170609 15:32:58 server id 933310 end_log_pos 733 CRC32 0xd907a353 Write_rows: table id 142 flags: STMT_END_F
### INSERT INTO `test`.`test`
### SET
### @1=1 /* INT meta=0 nullable=1 is_null=0 */
### @2=2 /* INT meta=0 nullable=1 is_null=0 */
# at 733 --这段event是xid event
#170609 15:32:58 server id 933310 end_log_pos 764 CRC32 0x9dbe0a6b Xid = 323
COMMIT/*!*/; ---这里是一个事物的结尾叫做xid event，但是注意不是733而是下一个event开始的位置764 或者是 xid event 的end_log_pos ，否则将会被回滚掉
# at 764
#170609 15:33:01 server id 933310 end_log_pos 829 CRC32 0x82aac64c GTID [commit=yes]
SET @@SESSION.GTID_NEXT= '89dfa8a4-cb13-11e6-b504-000c29a879a3:3'/*!*/;
所以我们认为一个事物的binlog是504到764
如果写为733会出现这种情况
mysqlbinlog testsla.000003 --start-position=504 --stop-position=733 -vv --base64-output=decode-rows
........
# at 689
#170609 15:32:58 server id 933310 end_log_pos 733 CRC32 0xd907a353 Write_rows: table id 142 flags: STMT_END_F
### INSERT INTO `test`.`test`
### SET
### @1=1 /* INT meta=0 nullable=1 is_null=0 */
### @2=2 /* INT meta=0 nullable=1 is_null=0 */
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */; --很明显没有xid event 没有commit而mysqlbinlog自己家了一个rollback而回滚掉了
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETI
好这里我们简单介绍一个事物binlog event的流程，正如我工具所展示的
>Gtid Event ：事物开始
-->Query Event：begin
---->Map Event ：表映射
------>Insert Event：正真的数据二进制格式
>Xid Event: commit
这事一个事物需要经历的event，在5.7中不开启GTID，GTID EVENT任然存在那叫匿名gtid event及NONYMOUS_GTID_LOG_EVENT，在5.6中
最多gtid event有变动，因为5.6的并行slave不依靠binlog group commit。
如果想了解这些event和infobin工具请参考的文章：
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
http://blog.itpub.net/7728585/viewspace-2133469/ 解析MYSQL BINLOG 二进制格式(6)--UPDATE_ROW_EVENT/DELETE_ROW_EVENT
http://blog.itpub.net/7728585/viewspace-2133502/ 解析MYSQL BINLOG 二进制格式(7)--Xid_log_event/XID_EVENT
http://blog.itpub.net/7728585/viewspace-2133506/ 解析MYSQL BINLOG 二进制格式(8)--GTID_LOG_EVENT/ANONYMOUS_GTID_LOG_EVENT及其他
http://blog