mysql-innodb-鎖

鎖的算法

Record Lock：單個行記錄上的鎖

• 經過主鍵索引，鎖定單行
• read committed隔離級別下采用。

Geo Lock：間隙鎖，鎖定一個範圍但不包含自己

• 能夠防止多個多個事務將記錄插入到同一個範圍內(Phantom Problem)
• 對於惟一鍵值對的鎖定，GeoLock會降級爲Record Lock。

Next-Key Lock：Geo Lock+Record Lock，鎖定一個範圍並鎖定記錄自己

• 在同一事務下，連續執行兩次sql語句可能致使不一樣的結果。第二次的sql可能會返回以前不存在的行
• 例如，假設表裏有id爲1，2，5三條記錄，對於select * from table where id >2 for update語句，Next-Key Lock鎖定的不止是5這一行，而是[2，+∞]。
• repeatable read隔離級別採用

數據問題

Dirty Read（髒讀問題）

• 一個事務中讀到了另外一個事務中未提交的數據，違反了數據庫隔離性，隔離級別read uncommitted。

Phantom Problem（幻讀問題）

• 在同一事務下，連續執行兩次sql語句可能致使不一樣的結果。第二次的sql可能會返回以前不存在的行。
• repeatable read隔離級別下，Innodb採用Next-Key Lock對查詢區域進行枷鎖解決幻讀問題。

不可重複讀

• 一個事務中讀到了另外一個事務中未提交的數據，違反了數據庫一致性。
• 通常狀況下，讀到的都是已提交的數據，不少廠商默認隔離級別就是read committed。
• MYSQL官方文檔將不可重複讀定義爲Phantom Problem(幻讀)，經過Next-Key Lock來解決幻讀問題。
• Next-Key Lock不只鎖住了掃描到的索引，同時鎖住了索引的覆蓋範圍。

丟失更新

• T1事務提交的更新操做被T2事務的更新覆蓋掉。
• 物理丟失更新不會出現，由於T2事務的操做會被T1阻塞。
• 邏輯丟失可能會出現：全部操做添加X排他鎖，數據庫串行化。

阻塞

• T2事務須要等待T1事務釋放資源後再進行資源佔有。

死鎖

• 兩個或以上的事務因爭奪資源形成的互相等待現象。

• 解決方案：

  1. 超時回滾：當超時的事務所佔權重較大或事務更新了較多行，undolog較大時回滾所用時間較長。

  2. wait-for graph(等待圖) 死鎖檢測方式：

     • 等待圖存儲了鎖的信息鏈表和事務等待鏈表，經過深度優先搜索進行遞歸排查。
     • 查到後選擇undolog較小的事務進行回滾。

鎖升級

• 若是數據庫設計者認爲鎖是一種稀缺資源，則會出現1000個行鎖升級爲頁鎖，頁鎖升級爲表鎖現象。
• Innodb沒有鎖升級。由於每一個事務都是對頁進行管理，且採用的是位圖存儲的方式。鎖開銷較小。