MySQL:Innodb 關於Handler_commit每次DML增加2的原因
簡單描述一下,也是本人的問的,水平有限,如果有誤請諒解。
原問題如下@mysqDBA:
請教一個問題。我每次insert一條語句,查詢show global status like 'Handler_commit'; 發現每次增加值是2,難道不應該是1嗎? 最簡單的insert into table a values(1);
一、問題展示
語句如下:
mysql> flush status; Query OK, 0 rows affected (0.10 sec) mysql> set sql_log_bin=1; Query OK, 0 rows affected (0.01 sec) mysql> insert into testm values(16,'gaopeng',34); Query OK, 1 row affected (0.15 sec) mysql> show status like '%commit%'; +----------------+-------+| Variable_name | Value | +----------------+-------+ | Com_commit | 0 || Com_xa_commit | 0 | | Handler_commit | 2 |+----------------+-------+3 rows in set (0.01 sec)
問為什麼 Handler_commit是2而不是1。
二、原因分析
其實對於這個問題只要看看這個Handler_commit指標增加的方式就可以看出原因。實際上這個指標出現在ha_commit_low函式中如下:
for (; ha_info; ha_info= ha_info_next) { int err; handlerton *ht= ha_info->ht(); if ((err= ht->commit(ht, thd, all))) { my_error(ER_ERROR_DURING_COMMIT, MYF(0), err); error=1; } DBUG_ASSERT(!thd->status_var_aggregated); thd->status_var.ha_commit_count++; //此處增加 ha_info_next= ha_info->next(); if (restore_backup_ha_data) reattach_engine_ha_data_to_thd(thd, ht); ha_info->reset(); /* keep it conveniently zero-filled */ }
可以清楚的看到ha_commit_count實際就是呼叫ht->commit的次數,由於有多個Handler的存在,因此這裡需要呼叫多次。對於開啟binlog+innodb的這種結構來講分別要做:
-
binlog的commit
-
Innodb的commit
後面會看到實際binlog的commit什麼都沒做,但是這是一種協議。
那麼如果我們關閉binlog可以發現Handler_commit為1瞭如下:
mysql> set sql_log_bin=0; Query OK, 0 rows affected (0.00 sec) mysql> insert into testm values(15,'gaopeng',34); Query OK, 1 row affected (0.10 sec) mysql> show status like '%commit%'; +----------------+-------+| Variable_name | Value | +----------------+-------+ | Com_commit | 0 || Com_xa_commit | 0 | | Handler_commit | 1 |+----------------+-------+3 rows in set (0.01 sec)
三、binlog commit棧幀
#0 binlog_commit (hton=0x3485e30, thd=0x7fff2c014430, all=false) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:1833#1 0x0000000000f64104 in ha_commit_low (thd=0x7fff2c014430, all=false, run_after_commit=false) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/handler.cc:1923#2 0x000000000185772b in MYSQL_BIN_LOG::process_commit_stage_queue (this=0x2e01c80, thd=0x7fff2c014430, first=0x7fff2c014430) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:8647#3 0x0000000001858f5d in MYSQL_BIN_LOG::ordered_commit (this=0x2e01c80, thd=0x7fff2c014430, all=false, skip_commit=false) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:9318#4 0x000000000185700c in MYSQL_BIN_LOG::commit (this=0x2e01c80, thd=0x7fff2c014430, all=false) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:8440#5 0x0000000000f63df8 in ha_commit_trans (thd=0x7fff2c014430, all=false, ignore_global_read_lock=false) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/handler.cc:1818
但是實際上binlog_commit什麼都沒做,因為在此之前他已經做完了需要做的事情比如flush、sync等
static int binlog_commit(handlerton *hton, THD *thd, bool all){ DBUG_ENTER("binlog_commit"); /* Nothing to do (any more) on commit. */ DBUG_RETURN(0); }
四、Innodb commit介面
#0 innobase_commit (hton=0x2e9edd0, thd=0x7fff2c014430, commit_trx=false) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/handler/ha_innodb.cc:4652#1 0x0000000000f64104 in ha_commit_low (thd=0x7fff2c014430, all=false, run_after_commit=false) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/handler.cc:1923#2 0x000000000185772b in MYSQL_BIN_LOG::process_commit_stage_queue (this=0x2e01c80, thd=0x7fff2c014430, first=0x7fff2c014430) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:8647#3 0x0000000001858f5d in MYSQL_BIN_LOG::ordered_commit (this=0x2e01c80, thd=0x7fff2c014430, all=false, skip_commit=false) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:9318#4 0x000000000185700c in MYSQL_BIN_LOG::commit (this=0x2e01c80, thd=0x7fff2c014430, all=false) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:8440#5 0x0000000000f63df8 in ha_commit_trans (thd=0x7fff2c014430, all=false, ignore_global_read_lock=false) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/handler.cc:1818
實際上innodb comit才是需要真正做的,這裡包含一些事情要做,比如事物狀態的改變,資源的釋放。
最後select也會增加Handler_commit,增加為1。
作者微訊號碼:gp_22389860
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/7728585/viewspace-2284290/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- MySQL 增加InnoDB系統表空間大小MySql
- 關於MySQL InnoDB表的二級索引是否加入主鍵的總結MySql索引
- MySQL不建議用UUID做innodb主鍵的幾條原因MySqlUI
- Mysql DML 新增資料MySql
- MySQL的DDL和DML操作語法MySql
- 關於$ is not defined的原因和解決辦法
- MySQL DML運算元據MySql
- MySQL Deadlocks in InnoDBMySql
- MySQL InnoDB 索引MySql索引
- MySQL 的資料管理及 DML 語句MySql
- KunlunDB對MySQL私有DML語法的支援MySql
- 探索MySQL的InnoDB索引失效MySql索引
- MySQL的show engine innodb statusMySql
- MySQL中2個select被阻塞場景的原因MySql
- 關於phpStudy中的phpmyadmin打不開的原因PHP
- 關於mysql的優化MySql優化
- 入門MySQL——DML語句篇MySql
- MySQL基礎之DML語句MySql
- MySQL InnoDB中的事務隔離級別和鎖的關係MySql
- MySQL 8.0 20個 InnoDB 及資料字典相關的新特性MySql
- mysql innodb索引高度MySql索引
- MySQL InnoDB update流程MySql
- mysql關於mysql.server的總結MySqlServer
- 重新學習Mysql資料庫2:『淺入淺出』MySQL 和 InnoDBMySql資料庫
- 關於InnoDB表資料和索引資料的儲存索引
- MySQL InnoDB的索引擴充套件MySql索引套件
- MySQL InnoDB 中的鎖機制MySql
- MySQL InnoDB搜尋索引的StopwordsMySql索引
- 關於mysql的query_cacheMySql
- mysql關於variable的總結MySql
- Mysql 關於event的詳解MySql
- 關於MySQL使用的時長MySql
- 關於mysql的最佳化MySql
- MySQL全面瓦解5:資料操作-DMLMySql
- MySQL-DML(Data Manipulation Language)詳解MySql
- MySQL alter 新增列對dml影響MySql
- InnoDB併發如此高,原因竟然在這?
- DDL、DML、DCL、DQL相關操作