MYSQL怎么發現及處理沒有commit 留下的大麻煩

這篇文章給大家介紹MYSQL怎么發現及處理沒有commit 留下的大麻煩，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

其實使用不同的數據庫開發應用程序，本身沒有什么，但開發人員如果不熟悉所使用的數據庫，還沿用自己熟悉數據庫的處理方式來處理新的數據庫，那顯然就會造成很多麻煩，這點對其他職業也是一樣。

今天想說的是，習慣使用ORACLE 的程序員，在MYSQL 留下的麻煩怎么被發現。這兩種數據庫在處理事務上是有不同的，oracle 默認不會自動commit， 而mysql 會默認 auto commit， 說道auto commit ，四大數據庫，只有oracle  一家是不默認commit。

那問題出在哪里，如果當初在程序員使用mysql 上設置了 auto commit 為非自動（線程級別，或global），而后期某些原因，又忘記了，記得MYSQL 本身是默認是 auto commit 那亂子就來了。所以一般都會看看developer 的歷史，如果開發的歷史用沒有使用過mysql 則必然會多留心。

下面有一個例子，系統有一個更新一直過不去，一直報

Lock wait timeout exceeded; try restarting transaction

哪遇到這樣的問題，會想起什么，怎么處理這個問題。 第一個想法是看看 

show engine innodb stauts

看到上面的圖，的反映是什么，有線程霸占某些記錄的row lock 太長時間了，造成其他的session無法操作對應的記錄。  在往深里面想，就有可能是沒有commit 而造成的 session idel 而事務running 的問題。

遇到這樣的問題，需要找出當前那個 session 正在idel 但其實里面的 transaction 在running 的狀態。 

1 找到正在sleep的session

2 查看耗時較長的session中運行的語句

通過查看到較長耗時的語句，以及語句的 processlist_id 就可以大致找到當前在作妖的線程ID。

然后kill他就好。

當然還有另外一種情況，就是程序里面由于不嚴謹，導致大批量的begin 但沒有commit, 那這樣用上面的方法就不趕趟了，怎么來更快的發現這樣的問題

通過上圖的語句，去發現相關的計數器是否一致在瘋狂的上漲，那就證明當前的數據庫系統中存在或可能存在這樣的問題。

關于MYSQL怎么發現及處理沒有commit 留下的大麻煩就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。