共計 1848 個字符，預計需要花費 5 分鐘才能閱讀完成。

這篇文章主要講解了“mysql autocommit= 0 引起的業務 hang 住問題分析”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著丸趣 TV 小編的思路慢慢深入，一起來研究和學習“mysql autocommit= 0 引起的業務 hang 住問題分析”吧！

背景

有用戶報告一個普通的 select  語句被 hang 住了，執行超時。查明之后發現是 autocommit 使用不當導致。這里將 case 簡化，說明復現步驟及原因。

復現

session1  建表并插入數據：create table if not exists t(id int primary key, c int);
set autocommit=0;
insert into t values(1,1);
insert into t values(2,2);
insert into t values(3,3);
commit;
select count(*) from t;
這個執行流程的目的很直觀，建表、插入數據、查詢結果。貌似沒有問題。維持 session1 不斷，新建一個連接 session2，執行  create table if not exists t(id int primary key, c int);
此時該語句處于等待狀態.
再新建一個連接 session3,  執行 select count(*) from t;  該語句處于等待狀態.
于是從業務上看就是一個 select  語句被 hang 住。

原因分析

MySQL Tips:  如果服務中某些語句無法執行完成，追查問題時第一步要先保留現場，pstack  pid of mysqld    tmplog 之一個常用的方法。

這兩個等待線程的棧如：#0 0x000000310ce0b7bb in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x000000000063ba46 in MDL_wait::timed_wait(THD*, timespec*, bool, char const*) ()
#2 0x000000000063e095 in MDL_context::acquire_lock(MDL_request*, unsigned long) ()
可以看到，堵在 MDL_wait.
簡單說明下什么是 MDL。試想，如果一個語句在執行一個表上的查詢過程中，表結構被改了，或者表被 drop，這樣會得到一個錯誤的結果。因此在一個事務持續期間，就需要對訪問的表結構作保護。這個就是 meta data lock (MDL).
很容易理解的，對表數據作增刪改查，需要對 MDL 加讀鎖，修改表結構、刪除表等操作則加寫鎖。

MySQL Tips: MDL 是 5.5 才加入的機制，5.1 版本下本文的 case 不會復現。 MySQL Tips:  事務中 MDL 申請時機是在首次使用時，釋放時機是在事務結束后。

也就是說文章開頭的這個 case，原因是 session2 等待在加寫鎖過程。而 session3 雖然只是加讀鎖，但與 session2 沖突，也需要等待。

session1 的事務

也就是說 session1 還持有表 t 的 MDL 讀鎖。但我們的事務明明已經提交 (commit) 了。這里就涉及到一個常見的誤解。以前有看過文章說，可以用 set autocommit= 0 開啟一個事務。其實這個描述不準確.

MySQL Tips: set autocommit= 0 是將本線程設置為非自動提交模式。在每個事務結束后，下個語句開始時自動新建一個事務。

這就意味著，session1 最后的那個 select count(*)操作，實際上之前隱含了一個 begin 操作。由于該事務沒有提交，因此 session1 持有表 t 的 MDL 讀鎖。因此對于業務方的建議就是，及時提交這些讀事務，或斷開連接。

MySQL Tips:  連接斷開時，MySQL 會自動回滾當前未提交的事務。  由于本 case 里面 session1 的最后一個事務只是一個 select 語句，因此回滾不影響業務。

感謝各位的閱讀，以上就是“mysql autocommit= 0 引起的業務 hang 住問題分析”的內容了，經過本文的學習后，相信大家對 mysql autocommit= 0 引起的業務 hang 住問題分析這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是丸趣 TV，丸趣 TV 小編將為大家推送更多相關知識點的文章，歡迎關注！