说明：文章基于Mysql V5.6 或者更高版本！
目录
1.Binlog 简单说明
Mysql Binlog 由许多的Event构成，MySQL 5.6版本中又加入gtid功能，每个事务都会有唯一的一个gtid序号与其对应，这个gtid序号在Binlog中也有一个专门的event类型与之对应，也就是GTID_LOG_EVENT。
2.文件内容查看
2.1. 通过Sql语句查看
show binlog events in 'bin文件名'
2.2. 通过命令行查看
mysqlbinlog --no-defaults --start-datetime="2021-12-09 11:20:00" bin文件完整路径
更多操作请参考：Mysql 常用命令收录
3.常见的事件类型
3.1. FORMAT_DESCRIPTION_EVENT
说明：
Binlog version 4中为了取代之前版本中的START_EVENT_V3事件而引入的。它是binlog文件中的第一个事件，而且，该事件只会在binlog中出现一次。MySQL根据FORMAT_DESCRIPTION_EVENT的定义来解析其它事件
作用：
它通常指定了MySQL Server的版本，binlog的版本，该binlog文件的创建时间
3.2. QUERY_EVENT
说明：
以文本的形式来记录事务的操作
作用：
- 事务开始时，执行的BEGIN操作。
- STATEMENT格式中的DML操作
- ROW格式中的DDL操作
示例：
3.3. ROWS_EVENT
说明：
对于ROW格式的binlog，所有的DML语句都是记录在ROWS_EVENT中。
ROWS_EVENT分为三种：WRITE_ROWS_EVENT，UPDATE_ROWS_EVENT，DELETE_ROWS_EVENT，分别对应insert，update和delete操作，对于QUERY_EVENT事件，是以文本形式记录DML操作的。而对于ROWS_EVENT事件，并不是文本形式，所以在通过mysqlbinlog查看基于ROW格式的binlog时，需要指定-vv --base64-output=decode-rows
示例：
3.4. XID_EVENT
说明：
在事务提交时，不管是STATEMENT还是ROW格式的binlog，都会在末尾添加一个XID_EVENT事件代表事务的结束。该事件记录了该事务的ID，在MySQL进行崩溃恢复时，根据事务在binlog中的提交情况来决定是否提交存储引擎中状态为prepared的事务
示例：
3.5. ROTATE_EVENT
说明：
当binlog文件的大小达到max_binlog_size的值或者执行flush logs命令时，binlog会发生切换，这个时候会在当前的binlog日志添加一个ROTATE_EVENT事件，用于指定下一个日志的名称和位置
示例：
3.6. GTID_LOG_EVENT
说明：
在启用GTID模式后，MySQL实际上为每个事务都分配了个GTID
补充：
GTID模式由参数“gtid_%”控制，详细如下：
事件存储结构【扩展】：
Event Header
| Filed | 说明 | 长度(单位：字节) |
|---|---|---|
| timestamp | 时间戳，表示该event的生成时间 | 4 |
| type_code | event类型 | 1 |
| server_id | 生成event的server_id | 4 |
| event_length | event的大小 | 4 |
| next_position | 下一个event的位置 | 4 |
| flags | event flags | 2 |
Event Data
| Field Value | 说明 |
|---|---|
| gtid_flags | |
| sid | 占用16字节，比如：b0d850c2-dbd0-11e9-90c3-080027b8bded |
| gno | 占用8字节，比如：b0d850c2-dbd0-11e9-90c3-080027b8bded:1，数字1就是gno |
| lt_type | 占用1字节，打开逻辑并行复制时，lt_type值为2 |
| last_committed | 占用8字节，lt_type 为2时才会有该值 |
| sequence_number | 占用8字节，lt_type 为2时才会有该值 |
| crc32校验码 | 4字节，是这个binlog event的crc32检验值 |
3.7. PREVIOUS_GTIDS_LOG_EVENT
说明：
开启GTID模式后，每个binlog开头都会有一个PREVIOUS_GTIDS_LOG_EVENT事件，记录了上一个binlog文件结束时执行到的gtid集合，如图：
事件存储结构【扩展】：
Event Header
| Filed | 说明 | 长度(单位：字节) |
|---|---|---|
| timestamp | 时间戳，表示该event的生成时间 | 4 |
| type_code | event类型 | 1 |
| server_id | 生成event的server_id | 4 |
| event_length | event的大小 | 4 |
| next_position | 下一个event的位置 | 4 |
| flags | event flags | 2 |
Event Data
| Field Value | 说明 |
|---|---|
| sid数量 | 占用8个字节。比如：b0d850c2-dbd0-11e9-90c3-080027b8bded:1-123,c1132ab1-e9be-11e9-a9d7-fa163ec9e7c2:1-6224，有两个server_uuid，因此sid数量为2 |
| sid | 占用16字节，比如：b0d850c2-dbd0-11e9-90c3-080027b8bded |
| sid对应的gtid段的数量 | 占用8字节。比如：b0d850c2-dbd0-11e9-90c3-080027b8bded:1-123:150-158，看最后的数字1-123:150-158，有两段gtid值，所以sid对应的gtid段的数量为2 |
| sid对应的gtid段的起始值 | 占用8字节，比如：1-123，起始值为1 |
| sid对应的gtid段的结束值 | 占用8字节，比如：1-123，结束值为123 |
| 若有多个段，依次解析 | |
| crc32校验码 | 4字节，是这个binlog event的crc32检验值 |
3.8. STOP_EVENT
说明：
当MySQL数据库停止时，会在当前的binlog末尾添加一个STOP_EVENT事件表示数据库停止。
4. 结尾
最后补充上传文章内容的思维导图，有兴趣的朋友可以下载，Mysql-binlog结构基础-思维导图