大約兩個禮拜前有同學拋出這個圖片問是怎么回事， 沒有時間隨即記下，有時間來處理。假期本來想懶懶，但答應(yīng)人家的事情，是要做的。
實際上，上面的圖是一個很經(jīng)典的MySQL的 record locks 的問題， 問題的起因應(yīng)該是 testdb.a 這張表的某條記錄，例如
select name from a where name = 'Jassica' for update;
在操作時，如果有其他語句在另一個session中也操作 name = 'Jassica' 這條記錄，就可能會產(chǎn)生上面的情況。
官方的文檔也是這樣說的，但實際上估計有人會不大信服， 怎么能模擬出那個show engine innodb status 中出現(xiàn)的上述的鎖信息。
下面我們就來做一做看看怎樣的情況能出現(xiàn)上面的信息
1 請創(chuàng)建一個簡單的表，具體有多簡單，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 模式下。
到此出現(xiàn)錯誤的信息的原因大概是弄清了， 其實到這里我們今天的主題才剛剛開始，問題是如果在 update 語句之前事務(wù)中還有其他的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 嗎？ 這就是今天關(guān)鍵，按照傳統(tǒng)數(shù)據(jù)庫來說， 當然是不能，應(yīng)該全部回滾。
那你的MYSQL 這里一8.019 為例 ， 答案是什么。
答案：不出所料，如果你的失敗的事務(wù)上面有其他的DML語句，一定會被執(zhí)行
這就和SQL SERVER 默認的事務(wù)執(zhí)行的方式一樣， 如果事務(wù)錯誤，則上面執(zhí)行的就不回 OMG， 我想著絕對和開發(fā)人員想的不大一樣。
實際上MYSQL 和 SQL SERVER 一樣，具體SQL SERVER 怎么做避免這個問題（請自行百度，或查找之前很久寫過這樣的文字）。
這里不管SQL SERVER ， MYSQL 實際上有一個參數(shù)默認是 disabled
我們需要打開，
innodb_rollback_on_timeout = 1 這個參數(shù)。他的功能是，自動回滾不會發(fā)生InnoDB鎖等待超時錯誤。并且這個參數(shù)需要關(guān)閉MYSQL 在配置文件中配置，在重啟動生效。
session 2
session 1
所以，如果有開發(fā)反應(yīng)數(shù)據(jù)庫的數(shù)據(jù)不大對頭的時候，那DB門是不是要關(guān)注這個參數(shù)是ENABLED OR DISABLED。
