有哪些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源碼系列問題”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！