MySQL中的鎖
概述
MyISAM支持表鎖,InnoDB支持表鎖和行鎖,默認為行鎖
表級鎖:開銷小,加鎖快,不會出現死鎖。鎖定粒度大,發生鎖沖突的概率最高,并發量最低
行級鎖:開銷大,加鎖慢,會出現死鎖。鎖力度小,發生鎖沖突的概率小,并發度最高
MyISAM表級鎖
鎖模式
- show status like 'table%' 可以分析鎖爭奪情況
- 表級鎖分為兩種模式:共享讀鎖,獨占寫鎖
- 讀讀共享,讀寫互斥,寫寫互斥,寫讀互斥(比如寫讀互斥,當一個用戶對user表進行寫的時候,會阻塞其他用戶的寫操作和讀操作)
加表鎖
- 在select的時候自動加讀鎖,在update delete insert時,自動加寫鎖
- 一般不需要用戶用lock table 命令直接顯式加鎖
顯示加表鎖時
- session1顯示給user表加鎖
lock table user read;
- session1此時不能讀取未鎖定的class表,所以lock table時要一次性鎖定要用到的表
- session1此時不能進行更新和插入,只能進行讀取
- 其他session可以讀取user表,但是更新會阻塞,而插入不會阻塞(可以通過設置concurrent_insert 系統變量來控制并發插入行為)
鎖調度
- 當一個進程請求user表的讀鎖,一個進程請求user表的寫鎖,即使讀請求先到,也是請求寫鎖成先成功
- 所以,MyISAM不適合大量的更新,因為大量更新會導致查操作很難獲得讀鎖
InnoDB行級鎖
行鎖
- 通過 show status like 'InnoDB_row_lock' 來分析行鎖爭奪情況
- 共享鎖S:允許一個事務去讀一行,阻止其他事務獲得相同數據集的排他鎖
- 排他鎖X:允許獲得排它鎖的事務更新數據,阻止其他事務取得相同數據集的共享鎖和排他鎖
意向鎖
- 所謂意向鎖就是意圖拿到鎖,所以要獲得共享鎖時,需要先獲得意向共享鎖
- 意向共享所IS,一個事務給一個數據行加共享鎖時,必須先獲得表的IS鎖
- 意向排它鎖IX,一個事務給一個數據行加排他鎖時,必須先獲得該表的IX鎖
間隙鎖
- 范圍查詢時,比如select * from user where id>50 ,這個時候即使最大id為51,不僅會給符合條件的行加鎖,也會給id大于51(不存在的記錄)的加鎖,這就是間隙鎖
- 間隙鎖解決了事務并發的幻讀問題
兼容情況
鎖 | S | X | IS | IX |
---|---|---|---|---|
S | Yes | No | Yes | No |
X | No | No | No | No |
IS | Yes | No | Yes | Yes |
IX | No | No | Yes | Yes |
加鎖
- 意向鎖是InnoDB自動加的
- 對于update insert delete 會自動加排它鎖
- 對于select不會自動加鎖
- Select * from user LOCK IN SHARE MODE 手動添加共享鎖
- select * from user For update 手動添加排它鎖
行鎖使用方式
- 通過索引條件檢索數據時,才使用行鎖,否則用表鎖
- 也就是如果select的where列不是索引列,那么此時,實際上是給整個表加鎖
- 檢索條件是索引時,又分索引是聚集索引還是非聚集索引,如果是聚集索引(索引上葉節點存放的整條記錄),在聚集索引上的加上行鎖,而如果是非聚集索引,要在非聚集索引記錄上加行鎖,又要在聚集索引上加行鎖
什么時候使用表鎖
- 事務需要更新表的大部分數據。如果每一行都加上排他鎖,鎖沖突嚴重,那么此時執行效率低
- 事務涉及多個表,比較復雜
死鎖
MyISAM
- 由于加的是表鎖,一次性鎖定要需要的表,所以不會出現死鎖
InnoDB
- 死鎖一般是事務相互等待對方資源
- 發生死鎖后,會自動檢測,并讓一個事務釋放鎖并回退
session1 | session2 |
---|---|
update user set username='jiajun' where id=1 | update user set username='jiajun' where id=2 |
update user set username='jiajun' where id=2 | update user set username='jiajun' where id=1 |
- 上面就是死鎖的列子
樂觀鎖與悲觀鎖
- 樂觀鎖和悲觀鎖是一種思想,不是上面提到的數據庫提供的鎖,是并發控制的一種手段
- 有這樣的場景,兩個事務對商品(id=666)進行下單
樂觀鎖
- 有一個statu字段,未下單為0,下單為1
- 先查statu字段,下單進行更新, 再查詢一次statu看是否與之前查的一樣,一樣的話commit,不一樣的話rollback
- 實現方式:加一個版本號或者時間戳,提交前進行一次比較
悲觀鎖
- 直接對id為666的行加排他鎖
- 實現方式:通過數據庫的鎖機制進行加鎖
對比
- 悲觀鎖比較謹慎,采用加鎖機制,一定程度下降低了并發性
- 樂觀鎖認為一般情況下不會發生沖突,并發性較好
- 從沖突量和重試代價來衡量,如果沖突很少,或者重試代價不會很嚴重,那么通常情況下應該選擇樂觀鎖,因為它能得到更好的并發性,而且更容易實現。但是,如果沖突的代價嚴重,那么就需要使用悲觀策略
兩段鎖原則
兩段鎖
- 是一個加鎖原則,一種協議
- 鎖操作分為兩個階段,加鎖階段只加鎖不放鎖,解鎖階段只放鎖不加鎖
- 比如一個事務中兩個update語句,此時執行完第一個update不會立刻放鎖,等加鎖階段完成后再進行放鎖,也就是加鎖和解鎖不相交
- 事務開始后就處于加鎖階段,一直到執行ROLLBACK和COMMIT之前都是加鎖階段。ROLLBACK和COMMIT使事務進入解鎖階段,即在ROLLBACK和COMMIT模塊中DBMS釋放所有封鎖。
我覺得分享是一種精神,分享是我的樂趣所在,不是說我覺得我講得一定是對的,我講得可能很多是不對的,但是我希望我講的東西是我人生的體驗和思考,是給很多人反思,也許給你一秒鐘、半秒鐘,哪怕說一句話有點道理,引發自己內心的感觸,這就是我最大的價值。(這是我喜歡的一句話,也是我寫博客的初衷)
作者:jiajun 我的博客園: http://www.cnblogs.com/-new/