mysql 的鎖以及間隙鎖

mysql 為并發事務同時對一條記錄進行讀寫時，提出了兩種解決方案：

成都創新互聯憑借專業的設計團隊扎實的技術支持、優質高效的服務意識和豐厚的資源優勢，提供專業的網站策劃、網站建設、網站制作、網站優化、軟件開發、網站改版等服務，在成都10年的網站建設設計經驗，為成都上千中小型企業策劃設計了網站。

1）使用 mvcc 的方法，實現多事務的并發讀寫，但是這種讀只是“快照讀”，一般讀的是歷史版本數據，還有一種是“當前讀”，一般加鎖實現“當前讀”，或者 insert、update、delete 也是當前讀。

2）使用加鎖的方法，鎖分為共享鎖（讀鎖），排他鎖（寫鎖）

快照讀：就是select

當前讀：特殊的讀操作，插入/更新/刪除操作，屬于當前讀，處理的都是當前的數據，需要加鎖。

mysql 在 RR 級別怎么處理幻讀的呢？一般來說，RR 級別通過 mvcc 機制，保證讀到低于后面事務的數據。但是 select for update 不會觸發 mvcc，它是當前讀。如果后面事務插入數據并提交，那么在 RR 級別就會讀到插入的數據。所以，mysql 使用 行鎖 + gap 鎖（簡稱 next-key 鎖）來防止當前讀的時候插入。

Gap Lock在InnoDB的唯一作用就是防止其他事務的插入操作，以此防止幻讀的發生。

Innodb自動使用間隙鎖的條件：

深入理解MySQL數據庫各種鎖（總結）

MyISAM和InnoDB存儲引擎使用的鎖：

封鎖粒度小：

由于InnoDB存儲引擎支持的是行級別的鎖，因此意向鎖（因為意向鎖是表鎖）其實不會阻塞除全表掃以外的任何請求。故表級意向鎖與行級鎖的兼容性如下所示

參考

參考

行鎖的三種算法：

這條語句阻止其他事務插入10和20之間的數字，無論這個數字是否存在。 間隙可以跨越0個，單個或多個索引值。

共享鎖：

排他鎖：

樂觀鎖：總是假設最好的情況，每次去拿數據的時候都認為別人不會修改（天真）， 操作數據時不會上鎖 ，但是 更新時會判斷在此期間有沒有別的事務更新這個數據，若被更新過，則失敗重試 ；適用于讀多寫少的場景。

樂觀鎖的實現方式 有：

關閉自動提交后，我們需要手動開啟事務。

上述就實現了悲觀鎖，悲觀鎖就是悲觀主義者，它會認為我們在事務A中操作數據1的時候，一定會有事務B來修改數據1,所以，在第2步我們將數據查詢出來后直接加上排它鎖（X）鎖，防止別的事務來修改事務1，直到我們commit后，才釋放了排它鎖。

mysql數據庫鎖MDL鎖的解釋

在我們系統中有一張表它的查詢概率非常高。 最近有個需求，需要對這個表增加一個字段 ，然而在增加字段的時候發現系統中有多個業務出現了超時操作，那么這個是什么原因導致的呢？經過查閱資料發現是數據庫的 MDL鎖+事務導致 的。

MDL鎖屬于表級別的元數據鎖。 表級別鎖分為數據鎖和元數據鎖，通常我們說的加鎖一般指的是加的數據鎖。跟數據鎖一樣，元數據鎖也分讀鎖和讀寫鎖。

MDL不需要顯示使用，在進行表操作時會自動加上 。當對表進行增刪改查時，會自動加上MDL讀鎖；當要對表進行加減字段的結構修改時，會自動加上MDL寫鎖。

MDL鎖的存在，其實是為了保證數據的一致性。 想象一下，假如沒有MDL鎖，一個查詢在遍歷表數據的過程中，另外一個線程執行了ALTER TABLE t DELETE COLUMN 'col_1'把col_1這一列刪掉了，那查詢結果就亂了，結果中是否應該有這一列數據？

：表示正常往下執行

：表示卡住了，即無法往下執行。

解釋：

步驟 1 2 正常執行。執行步驟2 時，會申請表customer的MDL的 SHARED_READ 鎖。

步驟3 會卡住， 因為此時會申請表customer的MDL的EXCLUSIVE鎖，但是事物一的事物沒有提交，此時是無法申請到EXCLUSIVE鎖，因為它們是互斥的。

步驟4 也會卡住，因為EXCLUSIVE鎖和SHARE_READ鎖是互斥的， 且EXCLUSIVE鎖的優先級更高 ，所以步驟4 也會卡住。

步驟5 事物提交，釋放表的SHARE_READ鎖，之后就可以執行6 和7 的操作了。

如果先執行事務二，在執行事務三，則是可以成功的，因為alter數據ddl語句，和事物無關。

因此在我們開發的過程中，需要避免大的事務操作，防止占有鎖的時間過長。

mysql讀數據時怎么加寫鎖

加鎖情況與死鎖原因分析

為方便大家復現，完整表結構和數據如下：

CREATE TABLE `t3` (

`c1` int(11) NOT NULL AUTO_INCREMENT,

`c2` int(11) DEFAULT NULL,

PRIMARY KEY (`c1`),

UNIQUE KEY `c2` (`c2`)

) ENGINE=InnoDB

insert into t3 values(1,1),(15,15),(20,20);

在 session1 執行 commit 的瞬間，我們會看到 session2、session3 的其中一個報死鎖。這個死鎖是這樣產生的：

1.?session1 執行 delete ?會在唯一索引 c2 的 c2 = 15 這一記錄上加 X lock（也就是在MySQL 內部觀測到的：X Lock but not gap）；

2.?session2 和 session3 在執行 insert 的時候，由于唯一約束檢測發生唯一沖突，會加 S Next-Key Lock，即對 (1,15] 這個區間加鎖包括間隙，并且被 seesion1 的 X Lock 阻塞，進入等待；

3.?session1 在執行 commit 后，會釋放 X Lock，session2 和 session3 都獲得 S Next-Key Lock；

4.?session2 和 session3 繼續執行插入操作，這個時候 INSERT INTENTION LOCK（插入意向鎖）出現了，并且由于插入意向鎖會被 gap 鎖阻塞，所以 session2 和 session3 互相等待，造成死鎖。

死鎖日志如下：

請點擊輸入圖片描述

INSERT INTENTION LOCK

在之前的死鎖分析第四點，如果不分析插入意向鎖，也是會造成死鎖的，因為插入最終還是要對記錄加 X Lock 的，session2 和 session3 還是會互相阻塞互相等待。

但是插入意向鎖是客觀存在的，我們可以在官方手冊中查到，不可忽略：

Prior to inserting the row, a type of gap lock called an insert intention gap lock is set. This lock signals the intent to insert in such a way that multiple transactions inserting into the same index gap need not wait for each other if they are not inserting at the same position within the gap.

插入意向鎖其實是一種特殊的 gap lock，但是它不會阻塞其他鎖。假設存在值為 4 和 7 的索引記錄，嘗試插入值 5 和 6 的兩個事務在獲取插入行上的排它鎖之前使用插入意向鎖鎖定間隙，即在（4，7）上加 gap lock，但是這兩個事務不會互相沖突等待。

當插入一條記錄時，會去檢查當前插入位置的下一條記錄上是否存在鎖對象，如果下一條記錄上存在鎖對象，就需要判斷該鎖對象是否鎖住了 gap。如果 gap 被鎖住了，則插入意向鎖與之沖突，進入等待狀態（插入意向鎖之間并不互斥）。總結一下這把鎖的屬性：

1. 它不會阻塞其他任何鎖；

2. 它本身僅會被 gap lock 阻塞。

在學習 MySQL 過程中，一般只有在它被阻塞的時候才能觀察到，所以這也是它常常被忽略的原因吧...

GAP LOCK

在此例中，另外一個重要的點就是 gap lock，通常情況下我們說到 gap lock 都只會聯想到 REPEATABLE-READ 隔離級別利用其解決幻讀。但實際上在 READ-COMMITTED 隔離級別，也會存在 gap lock ，只發生在：唯一約束檢查到有唯一沖突的時候，會加 S Next-key Lock，即對記錄以及與和上一條記錄之間的間隙加共享鎖。

通過下面這個例子就能驗證：

請點擊輸入圖片描述

這里 session1 插入數據遇到唯一沖突，雖然報錯，但是對 (15,20] 加的 S Next-Key Lock 并不會馬上釋放，所以 session2 被阻塞。另外一種情況就是本文開始的例子，當 session2 插入遇到唯一沖突但是因為被 X Lock 阻塞，并不會立刻報錯 “Duplicate key”，但是依然要等待獲取 S Next-Key Lock 。

有個困惑很久的疑問：出現唯一沖突需要加 S Next-Key Lock 是事實，但是加鎖的意義是什么？還是說是通過 S Next-Key Lock 來實現的唯一約束檢查，但是這樣意味著在插入沒有遇到唯一沖突的時候，這個鎖會立刻釋放，這不符合二階段鎖原則。這點希望能與大家一起討論得到好的解釋。

如果是在 REPEATABLE-READ，除以上所說的唯一約束沖突外，gap lock 的存在是這樣的：

普通索引（非唯一索引）的S/X Lock，都帶 gap 屬性，會鎖住記錄以及前1條記錄到后1條記錄的左閉右開區間，比如有[4,6,8]記錄，delete 6，則會鎖住[4,8）整個區間。

對于 gap lock，相信 DBA 們的心情是一樣一樣的，所以我的建議是：

1. 在絕大部分的業務場景下，都可以把 MySQL 的隔離界別設置為 READ-COMMITTED；

2. 在業務方便控制字段值唯一的情況下，盡量減少表中唯一索引的數量。

鎖沖突矩陣

前面我們說的 GAP LOCK 其實是鎖的屬性，另外我們知道 InnoDB 常規鎖模式有：S 和 X，即共享鎖和排他鎖。鎖模式和鎖屬性是可以隨意組合的，組合之后的沖突矩陣如下，這對我們分析死鎖很有幫助：

請點擊輸入圖片描述

mysql備份數據庫 怎么鎖表

MySQL8.x 中新增了一個輕量級的備份鎖，它允許在 online 備份的時候進行 DML 操作，同時可防止快照不一致。這個鎖禁止的操作很少，它禁止的操作包括：

文件的創建、刪除、改名

賬戶的管理

REPAIR TABLE

TRUNCATE TABLE

OPTIMIZE TABLE

備份鎖由?lock instance for backup?和?unlock instance?語法組成。使用這些語句需要 BACKUP_ADMIN 權限。

當前題目：mysql數據庫鎖怎么加,數據庫加鎖的作用
本文地址：http://vcdvsql.cn/article36/hspspg.html

成都網站建設公司_創新互聯，為您提供企業網站制作、網站內鏈、營銷型網站建設、移動網站建設、域名注冊、品牌網站制作

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯