这个部分描述了事件被写入binlog或者delay log中的属性。所有的事件有相同的整体结构，也就是包含事件头和事件数据：
+===================+
| event header |
+===================+
| event data |
+===================+具体的内容随着Mysql版本的升级而不同，这导致了binlog格式的不一致：
- v1：用于3.23版本
- v3：用于4.0.2到4.1版本
- v4：用于5.0及以上版本
v2的格式用于4.0.x的版本中，但是已经过期了，并且不再支持了。
有些事件的结构随着版本没有改变，而有些与版本有关。在所有的版本中，不同类型的事件在数据部分的结构不一样。
日志文件的第一个事件是特殊的。他是个符号事件，包含binlog版本和服务器版本。符号事件中的信息让程序能够决定日志文件的格式，这样剩余的事件内容才能被正确的解析出来。
下面说明下不同版本的binlog格式：
v1事件结构：
+=====================================+
| event | timestamp 0 : 4 |
| header +----------------------------+
| | type_code 4 : 1 |
| +----------------------------+
| | server_id 5 : 4 |
| +----------------------------+
| | event_length 9 : 4 |
+=====================================+
| event | fixed part 13 : y |
| data +----------------------------+
| | variable part |
+=====================================+头长度=13字节，数据长度=(事件长度-13)字节，y与事件类型有关。
v3事件结构
+=====================================+
| event | timestamp 0 : 4 |
| header +----------------------------+
| | type_code 4 : 1 |
| +----------------------------+
| | server_id 5 : 4 |
| +----------------------------+
| | event_length 9 : 4 |
| +----------------------------+
| | next_position 13 : 4 |
| +----------------------------+
| | flags 17 : 2 |
+=====================================+
| event | fixed part 19 : y |
| data +----------------------------+
| | variable part |
+=====================================+头长度=19字节，数据长度=（事件长度-19）字节，y与事件类型有关。
v4事件结构
+=====================================+
| event | timestamp 0 : 4 |
| header +----------------------------+
| | type_code 4 : 1 |
| +----------------------------+
| | server_id 5 : 4 |
| +----------------------------+
| | event_length 9 : 4 |
| +----------------------------+
| | next_position 13 : 4 |
| +----------------------------+
| | flags 17 : 2 |
| +----------------------------+
| | extra_headers 19 : x-19 |
+=====================================+
| event | fixed part x : y |
| data +----------------------------+
| | variable part |
+=====================================+头长度=x字节，数据长度=（事件长度-x）字节，固定数据部分长度=y字节，变量数据程度=（事件长度-(x+y)）字节。x由FDE（格式描述事件format description event）header_length给出。当前来说，x=19，所以extra_headers字段是空的。
y和事件类型有关，也是由FDE给出的。fixed-part的长度对于同一个事件类型是一样的，但是不同的事件类型是不一样的。
fixed-part有时候指的是post-header，变量部分有时候指的是payload或者body。
一、事件内容-写入约定
事件内容的写入约定如下：
- 数字是按照地位优先的格式写入的（最不重要字节有限），除非显式表示
- 表示位置或长度的值以字节形式写入，并且是无符号的
- 有些数字是以封包整数的形式写入的，这个格式后面再详细说明
-
字符串有以下几种格式：
- 字符串可能写入一个固定长度域中，右边以null填充（0x00）
- 可变长度的字符串前面包含一个表示字符串长度的内容
- 有些可变长度的字符串以null结尾，有些不是。每个字符串中有符号表示属于哪种情况。
- 对于null结尾的字符串，最前面是字符串长度，这个长度不包含结尾的null字节，除非显式表明
- 如果存在可变长度的字符串在事件结尾，并且事件前面没有任何内容，这个字符串的长度=事件长度-事件中其他内容的长度。
有些事件使用封包整数，这是一个特殊的格式，用来有效的描述无符号整数。封包整数可以存储一个8字节的整数，小整数（small integer）占用1、3或4字节。根据下面的表格，第一个字节的值决定了如何读这个数字：
| 第一个字节 | 格式 |
|---|---|
| 0-250 | 第一个字节就是数字（0-250），不需要额外的字节。 |
| 252 | 使用多于2字节，数字的范围是251-0xffff |
| 253 | 使用多于3字节，数字的范围是0xffff-0xfffff |
| 254 | 使用多于8字节，数字范围是0xfffff-0xffffffffffffffff |
二、事件头字段
每个事件以LOG_EVENT_HEADER_LEN长度开头，这个常量在v1格式中时13，在v3及以上格式中是19.
- v1：13字节：timestamp+type code+server ID+event length
- v3：19字节：v1的字段+next position+flags
- v4：19字节或更多：v3的字段+可能有其他信息
v1事件头：
+============================+
| timestamp 0 : 4 |
+----------------------------+
| type_code 4 : 1 |
+----------------------------+
| server_id 5 : 4 |
+----------------------------+
| event_length 9 : 4 |
+============================+v1头的13个字节也包含在其他版本的事件头中。
v3事件头
+============================+
| timestamp 0 : 4 |
+----------------------------+
| type_code 4 : 1 |
+----------------------------+
| server_id 5 : 4 |
+----------------------------+
| event_length 9 : 4 |
+----------------------------+
| next_position 13 : 4 |
+----------------------------+
| flags 17 : 2 |
+============================+和v1对比，v3以上中的事件头中包含两个额外的字段，总长度为19字节。
v4事件头
+============================+
| timestamp 0 : 4 |
+----------------------------+
| type_code 4 : 1 |
+----------------------------+
| server_id 5 : 4 |
+----------------------------+
| event_length 9 : 4 |
+----------------------------+
| next_position 13 : 4 |
+----------------------------+
| flags 17 : 2 |
+----------------------------+
| extra_headers 19 : x-19 |
+============================+v4的事件头中包含一个extra_headers字段，是为了以后扩展用。当前x=19，所以v4和v3当前格式一样。
注意：extra_headers么有在FORMAT_DESCRIPTION_EVENT或ROTATE_EVENT的头中出现。
在log_event.h中，包含几个事件头的常量：
- EVENT_TYPE_OFFSET = 4
- SERVER_ID_OFFSET = 5
- EVENT_LEN_OFFSET = 9
- LOG_POS_OFFSET = 13
- FLAGS_OFFSET = 17
事件头中包含以下信息：
- timestamp
4字节。表示的是语句开始执行的时间，格式与TIMESTAMP SQL数据类型一样。
- type_code
1字节。事件类型。1表示START_EVENT_V3，2表示QEURY_EVENT，以此类推。这些数字定义在log_event.h的Log_event_type的枚举类中。
- server id
4字节，产生这个事件的mysqld服务器id。这个是在服务器中配置文件配置的，用于主从复制。server id会在循环复制时避免死循环（开启了--log-slave-updates配置）。假设M1、M2和M3的server id分别是1、2、3，而且他们循环复制：M1是M2的主，M2是M3的主，M3是M1的主。他们的主从关系如下：
M1---->M2
^ |
| |
+--M3<-+客户端发起了一个插入语句给M1，M1执行了之后，写入了M1的binlog文件中，包含了server id为1。这个事件被发给了M2，M2也执行了这个语句，然后写binlog的时候，server id还是1，因为这个事件最初是由M1发起的。然后M3也收到了这个事件，执行完成后写入到M3的binlog文件时，server id还是1。然后M1收到了这个事件之后，在执行插入语句之前，可以分析出server id=1，也就是这个语句最初是本机发起的，这个语句会被忽略执行。
- event_length
4字节。事件的总长度，包含事件头和事件数据。大部分的事件小于1000字节，除非使用LOAD DATA INFILE（因为包含加载文件，所以他们可能很大）
-
next_position(v1不包含)：4字节。下个时间在master的binlog中的位置。这个格式在binlog和relay log中不一样，而且与server版本有关（对于relay log来说，与master的版本有关）
- v3版本的binlog：事件开头的偏移量，从binlog文件的开头开始计算。也就是说，在事件写入之前，等于tell()的值。
所以binlog的第一个事件的next_position=4，对于事件n和n+1，next_position(n+1)=next_position(n)+event_length(n)。 - v3版本的relay log，master是v1：可能是0，但是没法测试，因为现在已经基本没有3.23的服务器了。
- v3版本的relay log，master是v3：开头事件的偏移量和master中binlog文件一样，也是从master的binlog文件开头开始计算。
- v4版本的binlog：事件结尾的偏移量，从binlog文件开头开始计算。也就是说，等于在事件被写入之后，正好等于tell()的值。所以binlog中第一个事件的next_position=4+event_length，对于事件n和n+1，next_position(n+1)=next_position(n)+event_length(n+1)。
- v3版本的binlog：事件开头的偏移量，从binlog文件的开头开始计算。也就是说，在事件写入之前，等于tell()的值。
- flags（v1中没有）
2字节，详见下一节。
- extra_headers(v1和v3中不存在)
可变大小，当前为0。
事件flag
对于v3及以上版本中，事件头中包含一个2字节的时间flag在FLAGS_OFFSET=17位置上。在log_event.h中并没有定义。
当前的事件flag：
- LOG_EVENT_BINLOG_IN_USE_F=0x1（5.0.3新增）
表示一个binlog文件是否正确的被关闭了。这个标志位只对FORMAT_DESCRIPTION_EVENT生效。当这个事件被写入日志文件时，才会设置这个标志位。当日志文件后续被关闭后，这个标志位会被清除掉。（这是Mysql修改已经写完的binlog文件的唯一情况）。
- LOG_EVENT_THREAD_SPECIFIC_F=0x4(4.1.0新增)
仅供mysqlbinlog使用，使他能够正确的处理临时表。mysqlbinlog把binlog中的事件打印出来，让你能够理解打印出来的内容。但是如果两个独立的线程使用同样的临时表名，比如：
<thread id 1>
CREATE TEMPORARY TABLE t (a INT);
<thread id 2>
CREATE TEMPORARY TABLE t (a INT);这种情况下，简单的执行sql语句，会导致表t已经存在的错误。所以使用临时表的事件需要设置这个标志位，那样mysqlbinlog知道需要在变量值钱设置假的线程id，例如：
SET PSEUDO_THREAD_ID=1;
CREATE TEMPORARY TABLE t (a INT);
SET PSEUDO_THREAD_ID=2;
CREATE TEMPORARY TABLE t (a INT);这样，服务器接收到命令后就没有歧义了。所有情况下都打印SET PSEUDO_THREAD_ID，及时临时表没有用到，这样不会产生bug，但是会有点慢。
- LOG_EVENT_SUPPRESS_USE_F=0x8（4.1.7新增）
在一个语句被记录前，抑制产生USE语句。用于任何不需要使用默认数据库的事件中，比如CREATE DATABASE和DROP DATABASE。
- LOG_EVENT_UPDATE_TABLE_MAP_VERSION_F=0x10（5.1.4新增）
在事件写入日志文件中后，导致binlog内部的表映射版本增加。
过时的标志位：
- LOG_EVENT_TIME_F（4.1.1过期）。从未被设置过
- LOG_EVENT_FORCED_ROTATE_F（4.1.1过期）：这个标志位是在master的ROTATE_EVENT中配置的，但是没有任何用处。
三、事件数据字段（事件详细信息）
事件数据部分的结构依赖于事件类型：
- v1和v3版本中，事件类型完全决定了数据格式
- v4中，数据部分的解析除了依赖于事件类型，还依赖于格式描述事件的信息。这是因为在v4中，允许包含一个extra headers字段，这个字段的大小是在格式描述事件中定义的。实际上，当前这个字段是空的。
数据部分包含固定大小和可变大小两部分。两部分都可以为空，这由事件类型决定。（比如，STOP_EVENT只包含头，数据内容都为空）。
事件数据的大小=事件大小-事件头大小。下面的规则对binlog中所有的事件都通用：
- 对于所有相同类型的事件，固定部分的大小一样。
- 对于所有相同类型的事件，可变部分的大小可能不一样。
