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和myisam的dml效能對比MySql
- mysql innodb的行鎖(2)MySql
- MySQL 增加InnoDB系統表空間大小MySql
- MySQL/InnoDB和GroupCommit(2)MySqlMIT
- 關於主外來鍵關係DML父表和DML子表加鎖方式
- 【MYSQL】一個關於Innodb儲存引擎表的加鎖問題MySql儲存引擎
- 關於MySQL InnoDB表的二級索引是否加入主鍵的總結MySql索引
- 關於“No space left on device的原因”dev
- MySQL的InnoDB引擎強烈建議使用自增主鍵的原因MySql
- 關於innodb中查詢的定位方法
- MySQL·引擎特性·基於InnoDB的物理複製MySql
- MySQL不建議用UUID做innodb主鍵的幾條原因MySqlUI
- mysql innodb相關引數說明MySql
- 關於ORACLE 和MYSQL INNODB 觸發髒資料寫的機制對比OracleMySql
- MYSQL INNODB innodb_thread_concurrency相關引數理解MySqlthread
- 關於MYSQL INNODB index page header學習和實驗總結MySqlIndexHeader
- MySQL DML語句MySql
- 關於$ is not defined的原因和解決辦法
- 關於電梯阻塞原因的小思考
- 【實驗】【MySQL】MySQL的DML語言演示MySql
- mysql innodb的行鎖MySql
- MySQL InnoDB表的限制MySql
- 關於MySQLMySql
- 記憶體管理中關於記憶體每次增長的大小記憶體
- MySQL InnoDB 索引MySql索引
- innodb對於update,insert,delete關於auto_incremant的影響deleteREM
- 關於全域性臨時表DML特性案例體現
- Mysql加鎖過程詳解(2)-關於mysql 幻讀理解MySql
- 關於mysql的優化MySql優化
- MySQL的show engine innodb statusMySql
- mysql innodb的行鎖(3)MySql
- mysql innodb的行鎖(4)MySql
- 關於MYSQL DML(UPDATE DELETE)中的子查詢問題和ERROR 1093 (HY000)錯誤MySqldeleteError
- MySQL資料庫診斷:InnoDB關機問題MySql資料庫
- 頁面找不到js方法的原因,關於EasyUIJSUI
- 關於oracle的索引重建問題及原因分析Oracle索引
- 關於InnoDB表資料和索引資料的儲存索引
- mysql關於mysql.server的總結MySqlServer