有哪些MySQL源码系列问题

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