您好,登錄后才能下訂單哦!
這篇文章主要講解了“MySQL之InnoDB中鎖的情況分析”,文中的講解內容簡單清晰,易于學習與理解,下面請大家跟著小編的思路慢慢深入,一起來研究和學習“MySQL之InnoDB中鎖的情況分析”吧!
mysql> select @@version; +-----------+ | @@version | +-----------+ | 5.7.21 | +-----------+ 1 row in set (0.01 sec)
相對其他數據庫而言,MySQL的鎖機制比較簡單,其最顯著的特點是不同的存儲引擎支持不同的鎖機制。比如,MyISAM和MEMORY存儲引擎采用的是表級鎖(table-level locking);InnoDB存儲引擎既支持行級鎖(row-level locking),也支持表級鎖,但默認情況下是采用行級鎖。
表級鎖:開銷小,加鎖快;不會出現死鎖;鎖定粒度大,發生鎖沖突的概率最高,并發度最低。
行級鎖:開銷大,加鎖慢;會出現死鎖;鎖定粒度最小,發生鎖沖突的概率最低,并發度也最高。
Record Lock(記錄鎖):當個記錄的鎖(鎖住單條記錄)
記錄鎖只會鎖住索引的記錄,如果InnoDB存儲表在建立的時候沒有任何索引,那么這個鎖會使用隱式的主鍵來進行鎖定,如下圖
Gap Lock(間隙鎖):鎖定一個范圍,不包括記錄本身(只鎖數據前面的GAP)
如下圖為的鎖就是GAP鎖,就是不允許其他事務在索引列8之前的間隙插入新的記錄,也就是(3 , 8)這個區間。gap鎖 的作用僅僅是為了防止插入幻影記錄的而已
Next-Key Lock(臨鍵鎖):同時鎖住記錄和記錄前面的GAP,也就是Next-Key Lock = Record Lock + Gap Lock。
共享鎖 Share Locks (簡稱S鎖,屬于行鎖)
排它鎖 Exclusive Locks (簡稱X鎖,屬于行鎖)
意向共享鎖 Intention Share Locks (簡稱IS鎖,屬于表鎖)
意向排它鎖 Intention Exclusive Locks (簡稱IX鎖,屬于表鎖)
自增鎖 AUTO-INC Locks(屬于表鎖)
下面具體介紹下每種類型的鎖,我們先建一張innodb的表,sql如下
create table tab_with_index(id int,name varchar(10)) engine=innodb; alter table tab_with_index add index id(id); insert into tab_with_index values(1,'1'),(2,'2'),(3,'3'),(4,'4');
共享鎖就是多個事務對于同一個數據可以共享一把鎖,都能訪問數據庫,但是只能讀不能修改;
事務A:
select * from tab_with_index lock in share mode;
事務B:
select * from tab_with_index where id =1; // 可以查詢數據
update tab_with_index set name = 'aa' where id = 1 ;
注意:這里的修改語句會堵塞住,直到事務A提交之后才能操作成功。
排它鎖不能與其他鎖并存,如一個事務獲取了一個數據行的排它鎖,其他事務就不能在獲取該行的鎖,只有當前獲取排它鎖的事務可以對數據進行修改。(delete,update,create默認是排它鎖)
事務A:
select * from tab_with_index where id =1 for update;
事務B:
select * from tab_with_index where id =1; //可以獲取結果
select * from tab_with_index where id =1 for update; // 堵塞
select * from tab_with_index where id = 1 lock for share mode; // 堵塞
注意:事務B兩個sql都會堵塞住,也就是獲取不到共享鎖也獲取不到排它鎖,直到事務A提交之后才能操作成功。
意向共享鎖:表示事務準備給數據行加入共享鎖,也就是說一個數據行在加共享鎖之前必須先獲取該表的IS鎖。
意向排它鎖:表示事務準備給數據行加入排它鎖,也就是說一個數據行加排它鎖之前必須先獲取該表的IX鎖。
IS鎖和IX鎖是表級鎖,他們的提出僅僅為了在之后加表級別的S鎖和X鎖時可以快速判斷表中的記錄是否被上鎖,以避免用遍歷的方式來查看表中有沒有上鎖的記錄,也就是說其實IS鎖和IX鎖是兼容的,IX鎖和IX鎖是兼容的。 《MySQL是怎樣運行的》
針對自增列自增長的一個特殊的表級別鎖。
show variables like 'innodb_autoinc_lock_mode'; -- 默認值1,代表連續,事務未提交則ID永久丟失
1、事務及其ACID屬性
事務是由一組SQL語句組成的邏輯處理單元,事務具有4屬性,通常稱為事務的ACID屬性。
原子性(Actomicity):事務是一個原子操作單元,其對數據的修改,要么全都執行,要么全都不執行。 一致性(Consistent):在事務開始和完成時,數據都必須保持一致狀態。 隔離性(Isolation):數據庫系統提供一定的隔離機制,保證事務在不受外部并發操作影響的“獨立”環境執行。 持久性(Durable):事務完成之后,它對于數據的修改是永久性的,即使出現系統故障也能夠保持。
2、并發事務帶來的問題
相對于串行處理來說,并發事務處理能大大增加數據庫資源的利用率,提高數據庫系統的事務吞吐量,從而可以支持更多用戶的并發操作,但與此同時,會帶來一下問題:
臟讀: 一個事務正在對一條記錄做修改,在這個事務并提交前,這條記錄的數據就處于不一致狀態;這時,另一個事務也來讀取同一條記錄,如果不加控制,第二個事務讀取了這些“臟”的數據,并據此做進一步的處理,就會產生未提交的數據依賴關系。這種現象被形象地叫做“臟讀”
不可重復讀:一個事務在讀取某些數據已經發生了改變、或某些記錄已經被刪除了!這種現象叫做“不可重復讀”。
幻讀: 一個事務按相同的查詢條件重新讀取以前檢索過的數據,卻發現其他事務插入了滿足其查詢條件的新數據,這種現象就稱為“幻讀”
上述出現的問題都是數據庫讀一致性的問題,可以通過事務的隔離機制來進行保證。
數據庫的事務隔離越嚴格,并發副作用就越小,但付出的代價也就越大,因為事務隔離本質上就是使事務在一定程度上串行化,需要根據具體的業務需求來決定使用哪種隔離級別
臟讀 | 不可重復讀 | 幻讀 | |
---|---|---|---|
read uncommitted | √ | √ | √ |
read committed | √ | √ | |
repeatable read | √ | ||
serializable |
可以通過檢查InnoDB_row_lock狀態變量來分析系統上的行鎖的爭奪情況:
mysql> show status like 'innodb_row_lock%'; +-------------------------------+-------+ | Variable_name | Value | +-------------------------------+-------+ | Innodb_row_lock_current_waits | 0 | | Innodb_row_lock_time | 18702 | | Innodb_row_lock_time_avg | 18702 | | Innodb_row_lock_time_max | 18702 | | Innodb_row_lock_waits | 1 | +-------------------------------+-------+ --如果發現鎖爭用比較嚴重,如InnoDB_row_lock_waits和InnoDB_row_lock_time_avg的值比較高
3、InnoDB的行鎖模式及加鎖方法
共享鎖(S) :又稱讀鎖(lock in share mode)。允許一個事務去讀一行,阻止其他事務獲得相同數據集的排他鎖。若事務T對數據對象A加上S鎖,則事務T可以讀A但不能修改A,其他事務只能再對A加S鎖,而不能加X鎖,直到T釋放A上的S鎖。這保證了其他事務可以讀A,但在T釋放A上的S鎖之前不能對A做任何修改。 排他鎖(X) :又稱寫鎖(for update)。允許獲取排他鎖的事務更新數據,阻止其他事務取得相同的數據集共享讀鎖和排他寫鎖。若事務T對數據對象A加上X鎖,事務T可以讀A也可以修改A,其他事務不能再對A加任何鎖,直到T釋放A上的鎖。
mysql InnoDB引擎默認的修改數據語句:update,delete,insert都會自動給涉及到的數據加上排他鎖,select語句默認不會加任何鎖類型,如果加排他鎖可以使用select …for update語句,加共享鎖可以使用select … lock in share mode語句。所以加過排他鎖的數據行在其他事務中是不能修改數據的,也不能通過for update和lock in share mode鎖的方式查詢數據,但可以直接通過select …from…查詢數據,因為普通查詢沒有任何鎖機制。
4、InnoDB行鎖實現方式
InnoDB行鎖是通過給索引上的索引項加鎖來實現的,這一點MySQL與Oracle不同,后者是通過在數據塊中對相應數據行加鎖來實現的。InnoDB這種行鎖實現特點意味著:只有通過索引條件檢索數據,InnoDB才使用行級鎖,否則,InnoDB將使用表鎖!
1、在不通過索引條件查詢的時候,innodb使用的是表鎖而不是行鎖
create table tab_no_index(id int,name varchar(10)) engine=innodb; insert into tab_no_index values(1,'1'),(2,'2'),(3,'3'),(4,'4');
session1 | session2 |
---|---|
set autocommit=0 select * from tab_no_index where id = 1; | set autocommit=0 select * from tab_no_index where id =2 |
select * from tab_no_index where id = 1 for update | |
select * from tab_no_index where id = 2 for update; |
session1只給一行加了排他鎖,但是session2在請求其他行的排他鎖的時候,會出現鎖等待。原因是在沒有索引的情況下,innodb只能使用表鎖。
2、創建帶索引的表進行條件查詢,innodb使用的是行鎖
create table tab_with_index(id int,name varchar(10)) engine=innodb; alter table tab_with_index add index id(id); insert into tab_with_index values(1,'1'),(2,'2'),(3,'3'),(4,'4');
session1 | session2 |
---|---|
set autocommit=0 select * from tab_with_indexwhere id = 1; | set autocommit=0 select * from tab_with_indexwhere id =2 |
select * from tab_with_indexwhere id = 1 for update | |
select * from tab_with_indexwhere id = 2 for update; |
3、由于mysql的行鎖是針對索引加的鎖,不是針對記錄加的鎖,所以雖然是訪問不同行的記錄,但是依然無法訪問到具體的數據(這里是表鎖)
alter table tab_with_index drop index id; insert into tab_with_index values(1,'4');
session1 | session2 |
---|---|
set autocommit=0 | set autocommit=0 |
select * from tab_with_index where id = 1 and name='1' for update | |
select * from tab_with_index where id = 1 and name='4' for update 雖然session2訪問的是和session1不同的記錄,但是鎖的是具體表,所以需要等待鎖 |
感謝各位的閱讀,以上就是“MySQL之InnoDB中鎖的情況分析”的內容了,經過本文的學習后,相信大家對MySQL之InnoDB中鎖的情況分析這一問題有了更深刻的體會,具體使用情況還需要大家實踐驗證。這里是億速云,小編將為大家推送更多相關知識點的文章,歡迎關注!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。