溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本篇內容介紹了“Lock鎖的原理是什么”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！
MySQL中的行級鎖,表級鎖,頁級鎖中介紹過，行級鎖是Mysql中鎖定粒度最細的一種鎖，行級鎖能大大減少數據庫操作的沖突。行級鎖分為共享鎖和排他鎖兩種，本文將詳細介紹共享鎖及排他鎖的概念、使用方式及注意事項等。
數據庫是一個多用戶使用的共享資源。當多個用戶并發地存取數據時，在數據庫中就會產生多個事務同時存取同一數據的情況。若對并發操作不加控制就可能會讀取和存儲不正確的數據，破壞數據庫的一致性。
鎖是用于管理對公共資源的并發控制。也就是說在并發的情況下，會出現資源競爭，所以需要加鎖。加鎖解決了 多用戶環境下保證數據庫完整性和一致性。
Lock的對象是事務，用來鎖定的是數據庫中的對象，如表、頁、行。并且一般lock的對象僅在事務commit或rollback后進行釋放（不同事務隔離級別釋放的時間可能不同）。
死鎖是并發系統中常見的問題，同樣也會出現在數據庫MySQL的并發讀寫請求場景中。當兩個及以上的事務，雙方都在等待對方釋放已經持有的鎖或因為加鎖順序不一致造成循環等待鎖資源，就會出現“死鎖”。常見的報錯信息為 ” Deadlock found when trying to get lock... ”。
舉例來說A事務持有X1鎖 ，申請 X2 鎖，B事務持有 X2 鎖，申請 X1 鎖。A 和 B 事務持有鎖并且申請對方持有的鎖進入循環等待，就造成了死鎖。
為了分析死鎖，我們有必要對 InnoDB 的鎖類型有一個了解。
MySQL InnoDB引擎實現了標準行級別鎖：共享鎖( S lock ) 和排他鎖 ( X lock )
不同事務可以同時對同一行記錄加S鎖。
如果一個事務對某一行記錄加 X 鎖，其他事務就不能加 S 鎖或者 X 鎖，從而導致鎖等待。
如果事務T1持有行r的S鎖，那么另一個事務 T2 請求r的鎖時，會做如下處理：
T2 請求 S 鎖立即被允許，結果 T1 T2 都持有 r 行的 S 鎖
T2 請求 X 鎖不能被立即允許
如果T1持有r的 X 鎖，那么T2請求r的X、S鎖都不能被立即允許，T2 必須等待 T1 釋放 X 鎖才可以，因為 X 鎖與任何的鎖都不兼容。共享鎖和排他鎖的兼容性如下所示：
間隙鎖鎖住一個間隙以防止插入。假設索引列有2, 4, 8 三個值，如果對 4 加鎖，那么也會同時對(2,4)和(4,8)這兩個間隙加鎖。其他事務無法插入索引值在這兩個間隙之間的記錄。
但是，間隙鎖有個例外:
如果索引列是唯一索引，只會鎖住這條記錄(只加行鎖)，而不會鎖住間隙。 對于聯合索引且是唯一索引，如果 where 條件只包括聯合索引的一部分，那么依然會加間隙鎖。
使用普通索引鎖定；
使用多列唯一索引；
使用唯一索引鎖定多行記錄。
next-key lock 實際上就是 行鎖+這條記錄前面的 gap lock 的組合。假設有索引值10,11,13和 20,那么可能的 next-key lock 包括:
- (負無窮,10] - (10,11] - (11,13] - (13,20] - (20,正無窮)
在RR隔離級別下，InnoDB 使用 next-key lock 主要是防止幻讀問題產生。
臨鍵鎖，是記錄鎖與間隙鎖的組合，它的封鎖范圍，既鎖住記錄本身還鎖住索引之間的間隙。
注：臨鍵鎖的主要目的，也是為了避免幻讀(Phantom Read)。如果把事務的隔離級別降級為RC，臨鍵鎖則也會失效。
InnoDB為了支持多粒度的加鎖，允許行鎖和表鎖同時存在。為了支持在不同粒度上的加鎖操作，InnoDB 支持了額外的一種鎖方式，稱之為意向鎖( Intention Lock )，意向鎖是 InnoDB 自動加的,不需用戶干預。
意向鎖是將鎖定的對象分為多個層次，意向鎖意味著事務希望在更細粒度上進行加鎖。
意向鎖分為兩種：
意向共享鎖( IS )：事務有意向對表中的某些行加共享鎖：（事務務打算給數據行加行共享鎖，事務在給一個數據行加共享鎖前必須先取得該表的 IS 鎖）
意向排他鎖( IX )：事務有意向對表中的某些行加排他鎖：（事務打算給數據行加行排他鎖，事務在給一個數據行加排他鎖前必須先取得該表的 IX 鎖）
由于InnoDB存儲引擎支持的是行級別的鎖，因此意向鎖其實不會阻塞除全表掃描以外的任何請求。表級意向鎖與行級鎖的兼容性如下所示：
意向鎖有什么用？ 主要作用是處理行鎖和表鎖之間的矛盾，能夠顯示“某個事務正在某一行上持有了鎖，或者準備去持有鎖” 當我們需要加一個排他鎖時，需要根據意向鎖去判斷表中有沒有數據行被鎖定
比如事務A要在一個表上加S鎖，如果表中的一行已被事務B加了X鎖，那么該鎖的申請也應被阻塞。如果表中的數據很多，逐行檢查鎖標志的開銷將很大，系統的性能將會受到影響。為了解決這個問題，可以在表級上引入新的鎖類型來表示其所屬行的加鎖情況，這就引出了“意向鎖”的概念。
舉個例子，如果表中記錄1億，事務A把其中有幾條記錄上了行鎖了，這時事務B需要給這個表加表級鎖，如果沒有意向鎖的話，那就要去表中查找這一億條記錄是否上鎖了。
如果存在意向鎖，那么假如事務Ａ在更新一條記錄之前，先加意向鎖，再加Ｘ鎖，事務B先檢查該表上是否存在意向鎖，存在的意向鎖是否與自己準備加的鎖沖突，如果有沖突，則等待直到事務Ａ釋放，而無須逐條記錄去檢測。 事務Ｂ更新表時，其實無須知道到底哪一行被鎖了，它只要知道反正有一行被鎖了就行了。
單條索引上加鎖，record lock 永遠鎖的是索引，而非數據本身，如果innodb表中沒有索引，那么會自動創建一個隱藏的聚集索引，鎖住的就是這個聚集索引。
當一條sql沒有走任何索引時，那么將會在每一條聚集索引后面加X鎖，這個類似于表鎖，但原理上和表鎖應該是完全不同的。
命中單行記錄并且命中的條件字段是唯一索引或者主索引； update user_info set name=’張三’ where id=1; //這里的id是唯一索引,使用了Record Lock
Record Lock總是會去鎖住索引記錄，如果InnoDB存儲引擎表在建立的時候沒有設置任何一個索引，那么這時InnoDB存儲引擎會使用隱式的主鍵來進行鎖定。
插入意向鎖是在插入一行記錄操作之前設置的一種間隙鎖，這個鎖釋放了一種插入方式的信號，即多個事務在相同的索引間隙插入時如果不是插入間隙中相同的位置就不需要互相等待。假設某列有索引值2，6，只要兩個事務插入位置不同(如事務 A 插入3，事務 B 插入4)，那么就可以同時插入。
橫向是已持有鎖，縱向是正在請求的鎖：
“Lock鎖的原理是什么”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
