本篇内容介绍了“有哪些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 写入。
“有哪些MySQL源码系列问题”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注亿速云网站，小编将为大家输出更多高质量的实用文章！
