在分享本期直播内容之前，秉承有始有终及严谨的作风，国庆老师就第一次分享的关于 《MySQL 源码系列》 中的两个问题进行了补充与更正：

一、 trigger 的 event 到底怎么回放的，为什么没有主键冲突？

上次分享时，介绍了trigger trx 在 binlog 中 events 的顺序

 gtid event

 query event

 table_map_event(table1)

 table_map_event(table2)

 rows_event(table1)

 rows_event(table2)

 xid_event

实际在slave 进行回放的时候，他走的就不是 server 层的创建连接，执行语句了。而是直接调用每个 event 中的 do_apply_event 。比如 table map event ，它会将表的元信息保存起来。

到write_rows_event 呢， slave 调用函数如下

  |--do_exec_row

    |--write_row

      |-- handler::ha_write_row

    |-- write_row

可以看到是调用了引擎层的innodb::write_row 将数据插进去。

综上我们可以看到，trigger trx 在 slave 回放时，实际是绕过了 trigger ，直接交予存储引擎操作数据。因此也不会出现我们一开始说的，主键冲突的问题。

二、 trx 实际的生成顺序

我们说 trx 是由 event 构成的。比如 insert 语句，它包含的 events 是 gtid_log_event ， query_log_event,

table_map_log_event, write_rows_log_event, xid_log_event

我们说这些events 是在最后 trx 提交的时候生成的，实际不是哈，他们的实际生成顺序如下 ：

Gtid event ， Xid event 是在 ordered_commit 函数里生成的。这个涉及到 binlog 和 redo log 的一致性写入问题。

table map event 在 binlog_write_table_map 函数中生成，它接收了参数 has trans 标志是否是事务， need_binlog_rows_query 是否要生成 rows_query_log_event

在函数binlog_write_table_nap 函数中，会调用 binlog_start_trans_and_stmt ， 在该函数中生成 query_log_event

最后调用 write event 将所生成的 event 缓存在 thd 的 binlog_chache 中。

生成顺序: table_map_log_event, query_log_event, [rows_query_log_event]

缓存顺序: query_log_event, [rows_query_log_event], table_map_log_event

接着生成xid event ，最后在 ordered_commit 函数中生成 gtid event ，

statement 格式：

没有table_map_event 和 row_event 生成顺序

生成顺序：query_log_event( 储存语句 ) ， query_log_event(begin) ， xid event ， gtid event

binlog_write_table_map 中生成 table_map_event ， 使用 table_map_log_event 的另一个构造函数，从 table 对象中获取表信息，构造 table_map_log_event

接着调用 binlog_start_trans_and_stmt   生成 query_log_event(query_log 中设计的 regular trx 和 xa cases) 接着调用 cache_data 的 write_event 将 event 写入。