基础材料：
centos7.5 mysql 5.7.24 开启GTID ROW格式
binlog对于mysql是至关重要的，binlog与undo redo一起保证了数据的完整性，用于数据恢复，崩溃恢复、任一时间点恢复、甚至是任意一条数据的恢复。所有的高可用模式也都是基于binlog进行处理的。
本文主要对row格式下binlog日志输出内容进行说明。
首先执行flush logs截断当前日志，生成新日志，便于查看。然后插入一条记录，使用mysqlbinlog命令查看binlog。
mysql> flush logs;
mysql> insert into testxxxx values (110,111,111);
[root@mysql1 ~]# mysqlbinlog --no-defaults -vv mysql-binlog.000003
# at 732 #190312 16:23:46 server id 98 end_log_pos 797 CRC32 0xba637854 GTID last_committed=2 sequence_number=3 rbr_only=yes /*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/; SET @@SESSION.GTID_NEXT= '92b47a33-db57-11e8-accf-000c2988a781:21'/*!*/; # at 797 #190312 16:23:46 server id 98 end_log_pos 869 CRC32 0x82827bcc Query thread_id=48 exec_time=0 error_code=0 SET TIMESTAMP=1552379026/*!*/; BEGIN /*!*/; # at 869 #190312 16:23:46 server id 98 end_log_pos 922 CRC32 0x28c80e4b Table_map: `test`.`testxxxx` mapped to number 185 # at 922 #190312 16:23:46 server id 98 end_log_pos 970 CRC32 0x9d58cf96 Write_rows: table id 185 flags: STMT_END_F BINLOG ' kmyHXBNiAAAANQAAAJoDAAAAALkAAAAAAAEABHRlc3QACHRlc3R4eHh4AAMDAwMABksOyCg= kmyHXB5iAAAAMAAAAMoDAAAAALkAAAAAAAEAAgAD//huAAAAbwAAAG8AAACWz1id '/*!*/; ### INSERT INTO `test`.`testxxxx` ### SET ### @1=110 /* INT meta=0 nullable=0 is_null=0 */ ### @2=111 /* INT meta=0 nullable=1 is_null=0 */ ### @3=111 /* INT meta=0 nullable=1 is_null=0 */ # at 970 #190312 16:23:46 server id 98 end_log_pos 1001 CRC32 0xa52db5f9 Xid = 2932378 COMMIT/*!*/; # at 1001
1、上图中有许多# at开头的行，用于标示每个事件在binlog中的偏移量，例如# at 732表示该事件在binlog的位置是732字节之后
两个# at之间标示了mysql中的一个事件，而且在事件开始时也会通过end_log_pos标示事件结束的位置
binlog中一个完整的事务对应多个事件，两个GTID last_committed=2 sequence_number=3这样的行之间标识了一个完整的事务。
2、 server id 98表示产生该事务服务器id号为98，这是在my.cnf文件中定义的，该id在集群内不能重复。一来是对事务产生的server做标识，二来是在类似双主模式下的集群环境里用于中断binlog循环复制重做的问题（log-slave-updates = 1）。
3、 CRC32用于校验binlog文件的完整性。
4、 GTID表示启动了GTID属性
5、 last_committed=2组提交标识、同一组提交的事务具备相同的last_committed值，可以在从库并行重放，以减少同步延迟。
6、 sequence_number=3，事务对应的顺序号，该值单调递增，同时也标识了同一组提交事务的顺序，在从库设置slave_preserve_commit_order=1时，依赖该值模拟主库的提交顺序，在从库提交。以达到数据落盘过程完全一致。
7、 SET @@SESSION.GTID_NEXT= '92b47a33-db57-11e8-accf-000c2988a781:21'/*!*/;标识该事务使用的GTID序列号，92b47a33-db57-11e8-accf-000c2988a781为该主机的标识。后面的数字21标识事务号，随事务的提交而依次递增。该GTID标识正常情况下与show master status或show slave status的输出部分一致。
8、 SET TIMESTAMP=1552379026/*!*/;标识了该事务产生的时间，在一些特殊情况下保证数据一致性。比如使用了now函数的sql，可能延迟了很长时间才传到备库，此时now函数取该值插入，保证了与主库执行时间的一致。
9、 begin开始执行事务
10、Table_map: `test`.`testxxxx` mapped to number 185，标识要操作哪个库的哪张表
11、Write_rows: table id 185 flags: STMT_END_F，标识该操作类型，本次是插入操作对应Write_rows事件
12、
### INSERT INTO `test`.`testxxxx` ### SET ### @1=110 /* INT meta=0 nullable=0 is_null=0 */ ### @2=111 /* INT meta=0 nullable=1 is_null=0 */ ### @3=111 /* INT meta=0 nullable=1 is_null=0 */
这部分是具体的插入语句，@1=110表示在该表的第一个列插入值110，依次类推。如果此处是一个误删除操作，只要把前面的delete改为insert，再前滚这段binlog即可找回数据。由于语句执行时还有上下文关系，所以在不确定影响的情况下，不要只把SQL拿出来执行，而是前滚整个事务。
13、Xid = 2932378是保证数据完整性的一个标识，每个DML事务提交并完全写入binlog中结尾处一定会有Xid（DDL是没有的）。在redolog中也会记录该Xid值。在2PC提交机制中用此标识在redolog和binlog进行对比，崩溃时如果redolog没有commit，在redolog和binlog都有该值时，则事务重做，如果binlog没有找到该值时，则事务回滚。如果redolog也没有该值时，无需查找binlog，事务直接回滚。
14、最后由COMMIT标识提交事务
