MySQL 行鎖和表鎖的含義及區別詳解
一、前言
對於行鎖和表鎖的含義區別,在面試中應該是高頻出現的,我們應該對MySQL中的鎖有一個系統的認識,更詳細的需要自行查閱資料,本篇為概括性的總結回答。
MySQL常用引擎有MyISAM和InnoDB,而InnoDB是mysql預設的引擎。MyISAM不支援行鎖,而InnoDB支援行鎖和表鎖。
相對其他資料庫而言,MySQL的鎖機制比較簡單,其最顯著的特點是不同的儲存引擎支援不同的鎖機制。
MySQL大致可歸納為以下3種鎖:
- 表級鎖:開銷小,加鎖快;不會出現死鎖;鎖定粒度大,發生鎖衝突的概率最高,併發度最低。
- 行級鎖:開銷大,加鎖慢;會出現死鎖;鎖定粒度最小,發生鎖衝突的概率最低,併發度也最高。
- 頁面鎖:開銷和加鎖時間界於表鎖和行鎖之間;會出現死鎖;鎖定粒度界於表鎖和行鎖之間,併發度一般
如何加鎖?
MyISAM在執行查詢語句(SELECT)前,會自動給涉及的所有表加讀鎖,在執行更新操作(UPDATE、DELETE、INSERT等)前,會自動給涉及的表加寫鎖,這個過程並不需要使用者干預,因此使用者一般不需要直接用LOCK TABLE命令給MyISAM表顯式加鎖。
顯式加鎖:
上共享鎖(讀鎖)的寫法:lock in share mode,例如:
select math from zje where math>60 lock in share mode;
上排它鎖(寫鎖)的寫法:for update,例如:
select math from zje where math >60 for update;
二、表鎖
不會出現死鎖,發生鎖衝突機率高,併發低。
MyISAM引擎
MyISAM在執行查詢語句(select)前,會自動給涉及的所有表加讀鎖,在執行增刪改操作前,會自動給涉及的表加寫鎖。
MySQL的表級鎖有兩種模式:
- 表共享讀鎖
- 表獨佔寫鎖
讀鎖會阻塞寫,寫鎖會阻塞讀和寫
- 對MyISAM表的讀操作,不會阻塞其它程序對同一表的讀請求,但會阻塞對同一表的寫請求。只有當讀鎖釋放後,才會執行其它程序的寫操作。
- 對MyISAM表的寫操作,會阻塞其它程序對同一表的讀和寫操作,只有當寫鎖釋放後,才會執行其它程序的讀寫操作。
MyISAM不適合做寫為主表的引擎,因為寫鎖後,其它執行緒不能做任何操作,大量的更新會使查詢很難得到鎖,從而造成永遠阻塞
三、行鎖
會出現死鎖,發生鎖衝突機率低,併發高。
在MySQL的InnoDB引擎支援行鎖,與Oracle不同,MySQL的行鎖是通過索引載入的,也就是說,行鎖是加在索引響應的行上的,要是對應的SQL語句沒有走索引,則會全表掃描,行鎖則無法實現,取而代之的是表鎖,此時其它事務無法對當前表進行更新或插入操作。
CREATE TABLE `user` ( `name` VARCHAR(32) DEFAULT NULL,`count` INT(11) DEFAULT NULL,`id` INT(11) NOT NULL AUTO_INCREMENT,PRIMARY KEY (`id`) ) ENGINE=INNODB AUTO_INCREMENT=7 DEFAULT CHARSET=utf8 -- 這裡,我們建一個user表,主鍵為id -- A通過主鍵執行插入操作,但事務未提交 update user set count=10 where id=1; -- B在此時也執行更新操作 update user set count=10 where id=2; -- 由於是通過主鍵選中的,為行級鎖,A和B操作的不是同一行,B執行的操作是可以執行的 -- A通過name執行插入操作,但事務未提交 update user set count=10 where name='xxx'; -- B在此時也執行更新操作 update user set count=10 where id=2; -- 由於是通過非主鍵或索引選中的,升級為為表級鎖, -- B則無法對該表進行更新或插入操作,只有當A提交事務後,B才會成功執行
for update
如果在一條select語句後加上for update,則查詢到的資料會被加上一條排它鎖,其它事務可以讀取,但不能進行更新和插入操作
-- A使用者對id=1的記錄進行加鎖 select * from user where id=1 for update; -- B使用者無法對該記錄進行操作 update user set count=10 where id=1; -- A使用者commit以後則B使用者可以對該記錄進行操作
行鎖的實現需要注意:
- 行鎖必須有索引才能實現,否則會自動鎖全表,那麼就不是行鎖了。
- 兩個事務不能鎖同一個索引。
- insert,delete,update在事務中都會自動預設加上排它鎖。
行鎖場景:
A使用者消費,service層先查詢該使用者的賬戶餘額,若餘額足夠,則進行後續的扣款操作;這種情況查詢的時候應該對該記錄進行加鎖。
否則,B使用者在A使用者查詢後消費前先一步將A使用者賬號上的錢轉走,而此時A使用者已經進行了使用者餘額是否足夠的判斷,則可能會出現餘額已經不足但卻扣款成功的情況。
為了避免此情況,需要在A使用者操作該記錄的時候進行for update加鎖
擴充套件:間隙鎖
當我們用範圍條件而不是相等條件檢索資料,並請求共享或排他鎖時,InnoDB會給符合條件的已有資料記錄的索引項加鎖;對於鍵值在條件範圍內並不存在的記錄,叫做間隙
InnoDB也會對這個"間隙"加鎖,這種鎖機制就是所謂的間隙鎖
-- 使用者A update user set count=8 where id>2 and id<6 -- 使用者B update user set count=10 where id=5;
如果使用者A在進行了上述操作後,事務還未提交,則B無法對2~6之間的記錄進行更新或插入記錄,會阻塞,當A將事務提交後,B的更新操作會執行。
建議:
- 儘可能讓所有資料檢索都通過索引來完成,避免無索引行鎖升級為表鎖
- 合理設計索引,儘量縮小鎖的範圍
- 儘可能減少索引條件,避免間隙鎖
- 儘量控制事務大小,減少鎖定資源量和時間長度
到此這篇關於MySQL 行鎖和表鎖的含義及區別詳解的文章就介紹到這了,更多相關MySQL 行鎖和表鎖內容請搜尋我們以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援我們!