binlog是由MySQL数据库server层对数据库修改操作的记录，写入binlog时根据提交的顺序写入，binlog用于数据库主从复制、归档、备份恢复。其中，binlog是由一个个event组成的，不同的SQL语句对应不同的event，要了解binlog，就需要先了解binlog中都包含哪些event。
首先，我们开启一个新的binlog来进行验证。
查看当前数据库的binlog。
刷新binlog，重新生成一个新的binlog文件。
刷新36这个binlog后，暂时不进行任何写入操作，先看下全新的binlog里面包含哪些内容。
解析binlog，mysqlbinlog --no-defaults -vv mysql-bin-3306.000036
从解析后的日志中可以看出来，binlog是从"at 4"开始的，第一个event说明了binlog的格式、创建时间等，即FORMAT_DESCRIPTION_EVENT。第二个event是从"at 123"开始的，记录了Previous-GTIDS，描述前面所有binlog包含的gtid set，即PREVIOUS_GTIDS_LOG_EVENT。
现在我们向数据库中插入一条数据，来看下binlog是如何更新的。
此时，再解析binlog，查看内容。
从上面图片上可以看到，执行了一条insert语句后，新增加了"at 194"、"at 259" 、"at 331"、"at 380"、"at 423"这5个event。
"at 194"描述了下一个gtid号，但由于测试数据库没有开启gtid模式，因此描述为匿名gitd，即Anonymous_GTID_EVENT，如果开启了gtid mode，则对应的event会是GTID_EVENT。
"at 259"描述了时间戳TIMESTAMP、线程号pseudo_thread_id、sql_mode、客户端字符集character_set_client等信息，并且包含了begin语句，代表了事务开始，即QUERY_EVENT，该event会在事务的第一个dml语句的第一行数据被修改之后生成，一般是一个事务对应一个QUERY_EVENT。
"at 331"描述了insert语句的表emp在数据库中映射的id号，每个表有唯一的一个id号，且当MySQL实例重启、执行flush tables命令后，该table_id号会变化，并不是固定不变，该event称之为MAP_EVENT。
"at 380"才是真正记录insert语句内容的event，即WRITE_EVENT。该event用于记录insert语句插入的行数据。
"at 423"从图片上可以看出来，代表"commit"语句，代表着上面的insert事务结束，称之为XID_EVENT。
我们对上面的binlog内容进行总结，每生成一个新的binlog，至少包含2个event，第一个是FORMAT_DESCRIPTION_EVENT，第二个是PREVIOUS_GTIDS_LOG_EVENT。当执行了DML语句或者DDL语句之后，则会先生成GTID_EVENT或者Anonymous_GTID_EVENT，接着是QUERY_EVENT、MAP_EVENT以及对应的WRITE_EVENT/DELETE_EVENT/UPDATE_EVENT，最后是对应事务commit语句的XID_EVENT。