寫在前面：我們都是挖井人，也許挖到水的條件僅僅是需要保持專注而已！
行鎖
-
什麼是行鎖？
顧名思義，行鎖就是對數據行進行加鎖，mysql的行鎖是在引擎層實現的，innodb引擎支持行鎖，而myisam不支持所以myisam只能使用表鎖. -
行鎖的兩階段協議
在innodb事務中，行鎖是需要的時候才加上去的，但並不是不需要了就立即釋放，而是要等到事務結束再釋放
![行鎖兩階段協議]()
上述兩個事務A，B中，事務B必須等到事務A提交後才能執行，在事務A提交前會一直處於等待狀態 -
行鎖的注意事項
a. 通過行鎖的兩階段協議我們需要知道，如果一個事務中需要鎖多行，要把最可能造成鎖衝突，最可能影響併發度的鎖儘量往後放
（越往後，加鎖的時間越短，造成的影響也就越少）
b. InnoDB行鎖是通過給索引上的索引項加鎖來實現的，只有通過索引條件檢索數據，InnoDB才使用行級鎖，否則，InnoDB將使用表鎖！
c. 由於MySQL的行鎖是針對索引加的鎖，不是針對記錄加的鎖，所以雖然是訪問不同行的記錄，但是如果是使用相同的索引鍵，是會出現鎖衝突的
![角色表]()
![不主動提交事務]()
![鎖衝突了]()
-
死鎖和死鎖檢測
當多個線程都在同時等待相互間的鎖資源時，就會導致它們處於無線等待狀態，我們把這種狀態稱之爲死鎖
![事務A,B死鎖了]()
事務A在等待事務B釋放id=2的行鎖，而事務B在等待事務A釋放id=1的行鎖，然後。。。它們就進入了無限等待的死鎖狀態
通常處理死鎖問題有兩種策略：
a. 設置鎖超時時間，通過參數 innodb_lock_wait_timeout來調整
b. 發起死鎖檢測，發現死鎖後主動回滾死鎖鏈條中的某一個事務，讓其他事務得以執行，
將參數innodb_deadlock_detect設置爲on，mysql默認爲on（當併發量大的時候會極大的消耗CPU資源）
臆想面試：
-
如果處理死鎖問題？
如果我碰到這類面試問題，我想我只能先說出處理死鎖的兩種策略，然後說盡可能減少鎖衝突的可能性來降低死鎖概率，
具體業務需具體分析，採取的方案也大致不一 -
如果你要刪除表裏的前10000行數據，有以下三種方法可以做到：
a. 直接執行 delete from T limit 10000;
b. 在一個連接中循環執行20次 delete from T limit 500;
c. 在20個連接中同時執行 delete from T limit 500;
你會選哪個方案？
如果是我，我會選擇第二種；第一種鎖數據的時候太長，第三種不同連接容易造成鎖衝突！
上述多數內容借鑑學習有感於:
林曉斌老師mysql實戰45講
https://www.cnblogs.com/lushilin/p/6135374.html