事務A在執行完兩條update語句后，持有哪些鎖，以及在什么時候釋放。你可以驗證一下：實際上事務B的update語句會被阻塞，直到事務A執行commit之后，事務B才能繼續執行。
知道了這個答案，你一定知道了事務A持有的兩個記錄的行鎖，都是在commit的時候才釋放的。
假設你負責實現一個電影票在線交易業務，顧客A要在影院B購買電影票。我們簡化一點，這個業務需要涉及到以下操作：
-
從顧客A賬戶余額中扣除電影票價；
-
給影院B的賬戶余額增加這張電影票價；
-
記錄一條交易日志。
也就是說，要完成這個交易，我們需要update兩條記錄，並insert一條記錄。當然，為了保證交易的原子性，我們要把這三個操作放在一個事務中。那么，你會怎樣安排這三個語句在事務中的順序呢？
試想如果同時有另外一個顧客C要在影院B買票，那么這兩個事務沖突的部分就是語句2了。因為它們要更新同一個影院賬戶的余額，需要修改同一行數據。
根據兩階段鎖協議，不論你怎樣安排語句順序，所有的操作需要的行鎖都是在事務提交的時候才釋放的。所以，如果你把語句2安排在最后，
比如按照3、1、2這樣的順序，那么影院賬戶余額這一行的鎖時間就最少。
這就最大程度地減少了事務之間的鎖等待，提升了並發度。
如果這個影院做活動，可以低價預售一年內所有的電影票，而且這個活動只做一天。於是在活動時間開始的時候，你的MySQL就掛了。你登上服務器一看，CPU消耗接近100%，但整個數據庫每秒就執行不到100個事務。這是什么原因呢？
這時候，事務A在等待事務B釋放id=2的行鎖，而事務B在等待事務A釋放id=1的行鎖。 事務A和事務B在互相等待對方的資源釋放，就是進入了死鎖狀態。當出現死鎖以后，有兩種策略：
- 一種策略是，直接進入等待，直到超時。這個超時時間可以通過參數innodb_lock_wait_timeout來設置。
- 另一種策略是，發起死鎖檢測，發現死鎖后，主動回滾死鎖鏈條中的某一個事務，讓其他事務得以繼續執行。將參數innodb_deadlock_detect設置為on，表示開啟這個邏輯。
show variables like 'innodb_deadlock_detect';
一種頭痛醫頭的方法，就是如果你能確保這個業務一定不會出現死鎖，可以臨時把死鎖檢測關掉。但是這種操作本身帶有一定的風險，因為業務設計的時候一般不會把死鎖當做一個嚴重錯誤，
畢竟出現死鎖了，就回滾，然后通過業務重試一般就沒問題了，這是業務無損的。而關掉死鎖檢測意味着可能會出現大量的超時，這是業務有損的。
另一個思路是控制並發度。根據上面的分析，你會發現如果並發能夠控制住，比如同一行同時最多只有10個線程在更新，那么死鎖檢測的成本很低，
就不會出現這個問題。一個直接的想法就是，在客戶端做並發控制。但是，你會很快發現這個方法不太可行，因為客戶端很多。我見過一個應用，有600個客戶端，
這樣即使每個客戶端控制到只有5個並發線程，匯總到數據庫服務端以后，峰值並發數也可能要達到3000。
因此，這個並發控制要做在數據庫服務端。如果你有中間件，可以考慮在中間件實現；如果你的團隊有能修改MySQL源碼的人，
也可以做在MySQL里面。基本思路就是，對於相同行的更新，
在進入引擎之前排隊。這樣在InnoDB內部就不會有大量的死鎖檢測工作了。
如果團隊里暫時沒有數據庫方面的專家，不能實現這樣的方案，能不能從設計上優化這個問題呢？
你可以考慮通過將一行改成邏輯上的多行來減少鎖沖突。還是以影院賬戶為例，可以考慮放在多條記錄上，比如10個記錄，影院的賬戶總額等於這10個記錄的值的總和。
這樣每次要給影院賬戶加金額的時候，隨機選其中一條記錄來加。這樣每次沖突概率變成原來的1/10，可以減少鎖等待個數，也就減少了死鎖檢測的CPU消耗。
這個方案看上去是無損的，但其實這類方案需要根據業務邏輯做詳細設計。如果賬戶余額可能會減少，比如退票邏輯，那么這時候就需要考慮當一部分行記錄變成0的時候，
代碼要有特殊處理。