MYSQL事務錯誤不回滾的問題怎么解決

本篇內容介紹了“MYSQL事務錯誤不回滾的問題怎么解決”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

大約兩個禮拜前有同學拋出這個圖片問是怎么回事， 沒有時間隨即記下，有時間來處理。假期本來想懶懶，但答應人家的事情，是要做的。

實際上，上面的圖是一個很經典的MYSQL的 record locks 的問題， 問題的起因應該是 testdb.a 這張表的某條記錄，例如

select name from a where name = 'Jassica' for update; 

在操作時，如果有其他語句在另一個session中也操作 name = 'Jassica' 這條記錄，就可能會產生上面的情況。

官方的文檔也是這樣說的，但實際上估計有人會不大信服， 怎么能模擬出那個show engine innodb status 中出現的上述的鎖信息。

下面我們就來做一做看看怎樣的情況能出現上面的信息

1 請創建一個簡單的表，具體有多簡單，1 要有主鍵， 2 要有一個非主鍵的字段，例如varchar(30)， 然后輸入一些信息，類似下面這樣。

然后啟動兩個 sessions 

1  session 1 begin;

2  session 1 update a set name = 'aaa'  where name > 'PPP';

3  session 2 begin;

4  session 2 update a set name = 'PPP' where name > 'Jassica';

然后和上面同學給我的截圖類似的鎖的信息就有了。

這里有兩個問題

1 name > 'PPP' 我們并不知道到底有幾個記錄被UPDATE 

2  name > 'Jassica"  又有幾條記錄我們也不知道

問題1  有5條記錄被更新, 符合name > 'PPP' 的有5條記錄

問題2  > 'Jassica' 的

所以死鎖信息中

的信息就是 sinomina , x_professor, x_man   四條記錄。

與SESSION 2 中的要更新的 5條記錄，有沖突。

以上均在MYSQL 8.019  RC 模式下。

到此出現錯誤的信息的原因大概是弄清了， 其實到這里我們今天的主題才剛剛開始，問題是如果在 update 語句之前事務中還有其他的udpate語句， 到底是回滾不回滾。

答案是：  不 不 不回滾

我們看一下是不是這樣：

1  session 1 begin;

2  session 1 update a set name = 'aaa'  where name > 'PPP';

3  session 2 begin;

4  session 2 update a set name = '111111' where name = 'PPP';

5  session 2 update a set name = 'PPP' where name > 'Jassica';

6  session 1 commit;

7  session 2 commit;

session 2  失敗了， 到底 PPP  變成了 111111 嗎？  這就是今天關鍵，按照傳統數據庫來說， 當然是不能，應該全部回滾。

那你的MYSQL 這里一8.019 為例 ， 答案是什么。

答案：不出所料，如果你的失敗的事務上面有其他的DML語句，一定會被執行

這就和SQL SERVER 默認的事務執行的方式一樣， 如果事務錯誤，則上面執行的就不回 OMG， 我想著絕對和開發人員想的不大一樣。

實際上MYSQL 和 SQL SERVER 一樣，具體SQL SERVER 怎么做避免這個問題（請自行百度，或查找之前很久寫過這樣的文字）。

這里不管SQL SERVER ， MYSQL 實際上有一個參數默認是 disabled

我們需要打開， innodb_rollback_on_timeout = 1 這個參數。他的功能是，自動回滾不會發生InnoDB鎖等待超時錯誤。并且這個參數需要關閉MYSQL 在配置文件中配置，在重啟動生效。

session 2

session 1

所以，如果有開發反應數據庫的數據不大對頭的時候，那DB門是不是要關注這個參數是ENABLED OR DISABLED。

“MYSQL事務錯誤不回滾的問題怎么解決”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！