一文搞懂Mysql中的共享鎖、排他鎖、悲觀鎖、樂觀鎖及使用場景
一、常見鎖類型
- 表級鎖,鎖定整張表
- 頁級鎖,鎖定一頁
- 行級鎖,鎖定一行
- 共享鎖,也叫S鎖,在MyISAM中也叫讀鎖
- 排他鎖,也叫X鎖,在MyISAM中也叫寫鎖
- 悲觀鎖,抽象性質,其實不真實存在
- 樂觀鎖,抽象性質,其實不真實存在
常見鎖類型
二、Mysql引擎介紹
- 其實mysql中的引擎有很多種類,其中InnoDB和MyISAM引擎最常用
- 在mysql5.5版本前默認使用MyISAM引擎,之後使用InnoDB引擎
- 查看數據庫引擎命令如下
show variables like '%storage_engine%';
三、常用引擎間的區別
- MyISAM 操作數據都是使用的表鎖,你更新一條記錄就要鎖整個表,導致性能較低,並發不高。當然同時它也不會存在死鎖問題。
- 而 InnoDB 與 MyISAM 的最大不同有兩點:一是 InnoDB 支持事務;二是 InnoDB 采用瞭行級鎖。
- 在 Mysql 中,行級鎖並不是直接鎖記錄,而是鎖索引。索引分為主鍵索引和非主鍵索引兩種,如果一條sql 語句操作瞭主鍵索引,Mysql 就會鎖定這條主鍵索引;如果一條語句操作瞭非主鍵索引,MySQL會先鎖定該非主鍵索引,再鎖定相關的主鍵索引。
- InnoDB 行鎖是通過給索引項加鎖實現的,如果沒有索引,InnoDB 會通過隱藏的聚簇索引來對記錄加鎖。也就是說:如果不通過索引條件檢索數據,那麼InnoDB將對表中所有數據加鎖,實際效果跟表鎖一樣。因為沒有瞭索引,找到某一條記錄就得掃描全表,要掃描全表,就得鎖定表。
四、共享鎖與排他鎖
數據庫的增刪改操作默認都會加排他鎖,而查詢不會加任何鎖。
共享鎖:對某一資源加共享鎖,自身可以讀該資源,其他人也可以讀該資源(也可以再繼續加共享鎖,即 共享鎖可多個共存),但無法修改。要想修改就必須等所有共享鎖都釋放完之後。
排他鎖:對某一資源加排他鎖,自身可以進行增刪改查,其他人無法進行任何操作。
//共享鎖 select * from 表名 lock in share mode //排他鎖 select * from 表名 for update
五、排他鎖的實際應用
- 這裡我們以兩個操作數據庫的請求為例,假設這兩個請求分別為T1和T2
- 假設T1為查詢請求,而T2為更新數據請求,在T1查詢很長時間的時候,還沒有返回結果,但是這時候T2過來請求更新瞭
- 這個流程應該是: T1運行加共享鎖、T2運行、發現T1未完成等待其完成、T1完成、T2開始執行
- T2之所以要等待,是因為T2執行更新的時候需要給表加排他鎖,但是數據庫規定,不能在同一資源上同時共存這兩種鎖,所以T2必須等T1執行完,釋放鎖後,才可以正常操作
T1: select * from 表名 lock in share mode //假設還未返回結果 T2: update 表名 set name='autofelix'
六、共享鎖的實際應用
- 如果T1和T2都是執行的查詢,也就是都加共享鎖
- 這時候就不用等待,可以立馬執行
- 因為同一資源上可以同時存在多個共享鎖,也被稱為,共享鎖與共享鎖兼容
- 意味著共享鎖不阻止其他人同時讀取資源,但是阻止其他人修改資源
T1: select * from table lock in share mode T2: select * from table lock in share mode
七、死鎖的發生
- 假設T1和T2都同時執行2個資源操作,分別是查詢和更新數據
- 假設T1和T2同時達到select,T1對表加共享鎖,而T2也加上瞭共享鎖
- 當T1的select執行完畢,準備執行update時
- 根據鎖機制,T1的共享鎖必須升級到排他鎖才可以執行接下來的update操作
- 在升級排他鎖之前,必須等T2的共享鎖釋放,同理,T2也在等T1的共享鎖釋放
- 於是都在等待對方的鎖釋放,導致程序卡死,這種情況就是死鎖
T1: 開啟事務,執行查詢更新兩個操作 select * from table lock in share mode update table set column1='hello' T2: 開啟事務,執行查詢更新兩個操作 select * from table lock in share mode update table set column1='world'
八、另一種發生死鎖的情景
- 當T1和T2都是隻執行更新語句的時候
- 如下程序所示,這種語句非常的常見,很多人覺得他會產生死鎖,其實要看情況
- 如果id是主鍵,由於主鍵機制,並不需要全表掃描,直接可以更新當前數據,所以不會產生死鎖
- 如果id是普通字段,那麼當T1加上排他鎖之後,T2為瞭找到id=20條數據,必須進行全表掃描,當他掃到第10條的時候,發現這裡有排他鎖,導致全表掃描進行不下去,就會導致等待
T1: begin update table set content='hello' where id=10 T2: begin update table set content='world' where id=20
九、死鎖的解決方式
- 就是讓T1和T2順序執行,比如T1在執行完select後,立馬給自身加上排他鎖,這樣T2不得不等待T1執行完才能繼續
- 但是如果有很多請求過來的話,都必須等待,這對用戶特別的不友好
- 所以,某些數據庫引入瞭另一種方式,叫做更新鎖,這裡mysql除外,不存在更新鎖
- 更新鎖其實就是排他鎖的另一種實現,隻是他允許其他人讀的同時加共享鎖,但是不允許其他操作,除非釋放瞭更新鎖
- 流程大概如此: T1執行完select加上更新鎖,T2執行查詢完,準備加更新鎖,發現已經有瞭,就等待,其他請求過來,如果查詢是不受影響的,但是更新才等待
- 這相比上面的查詢也要等待增加瞭效率
T1: begin select * from table for update update table set content='hello' T2: begin select * from table for update update table set content='world'
T1: begin select * from table [加更新鎖操作] update table set content='hello' T2: begin select * from table [加更新鎖操作] update table set content='world'
十、意向鎖和計劃鎖
- 計劃鎖與程序猿無關,不需要瞭解
- 意向鎖,Innodb特有,分為意向共享鎖和意向排他鎖
- 意向共享鎖: 表示事務獲取共享鎖時,必須先得獲取該表的意向共享鎖
- 意向排他鎖: 表示事務獲取排他鎖時,必須先得獲取該表的意向排他鎖
- 我們知道要對整個表加鎖,必須保證表內不存在任何鎖
- 如果一行行的去檢查是否加鎖,效率必然極低,這時候可以檢測意向鎖是否被占用即可
十一、樂觀鎖和悲觀鎖
- 樂觀鎖和悲觀鎖都是針對select而言的
- 比如在商品搶購中,用戶購買後庫存需要減1,而很多用戶同時購買時,讀出來的庫存數量一樣,然後多個用戶同時用該庫存去減1
- 這種做法必然會出現很大的漏洞,如果向在淘寶,京東出現這種情況,你就可以打包回傢種地瞭
- 這種情況如何解決呢,其實可以使用悲觀鎖進行解決,說白瞭也就是排他鎖
- 用戶進來查庫存的時候,就加上排他鎖,等他所有操作完成後,再釋放排他鎖,讓其他人進來
- 不讓用戶等待,就可以使用樂觀鎖方式解決,樂觀鎖一般靠表的設計和時間戳來實現
- 一般是在表中添加version或者timestamp時間戳字段
- 這樣就會保證如果更新失敗,就表示有其他程序更新瞭數據庫,就可以通過重試解決
update table set num=num-1 where id=10 and version=12
總結
到此這篇關於一文搞懂Mysql中共享鎖、排他鎖、悲觀鎖、樂觀鎖及使用場景的文章就介紹到這瞭,更多相關Mysql共享鎖、排他鎖、悲觀鎖、樂觀鎖內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet!