大約兩個禮拜前有同學拋出這個圖片問是怎麼回事， 沒有時間隨即記下，有時間來處理。假期本來想懶懶，但答應人家的事情，是要做的。
實際上，上面的圖是一個很經典的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。
QQ羣有電子書自取，可能會加不上人數可能滿了
