我是少俠露飛,博客不僅是筆記,更是一種思考,一種分享,
引言
MySQL的鎖機制是面試中的難點,也是時常讓開發頭疼的問題,今天少俠就做個總結,
表鎖、頁鎖及行鎖
表鎖,顧名思義就是鎖住整張表,當一個事務在操作的時候,其它所有事務只能等待,如果是訪問量比較大的表,在并發場景下可謂是災難級的吞吐量,特點:開銷小,加鎖快;不會出現死鎖;鎖定粒度大,發生鎖沖突概率高,并發度最低,頁鎖,就是鎖住一頁,我們知道MySQL資料都是一頁一頁加載到記憶體的,每頁16K(比方說一個表只有一個欄位,并且占據記憶體是8000位元組,那一次只能加載兩行資料到頁內),行鎖,就是每次只鎖定被操作的行,是比表鎖、頁鎖維度都要小的一種鎖定方式,特別需要注意的是,MySQL的行鎖鎖住的都是索引,而不是記錄,務必牢記!特點:開銷大,加鎖慢;會出現死鎖;鎖定粒度小,發生鎖沖突的概率低,并發度高,
共享鎖和排它鎖
共享鎖:共享鎖又叫做讀鎖或S鎖,加上共享鎖后在事務結束之前其他事務只能再加共享鎖、只能對其進行讀操作不能寫操作,除此之外其他任何型別的鎖都不能再加了,
# 加上lock in share mode
SELECT description FROM table lock in share mode;
排他鎖:排他鎖又叫寫鎖或X鎖,某個事務對資料加上排他鎖后,只能這個事務對其進行讀寫,在此事務結束之前,其他事務不能對其加任何鎖,可以讀取(因為MySQL讀取是不加鎖的),不能進行寫操作,需等待其釋放,
# 加上for update
SELECT description FROM table for update;
注意,無論是共享鎖還是排它鎖都是行鎖,
樂觀鎖和悲觀鎖
在Java中常見的采用CAS演算法實作的樂觀鎖的典型的例子就是原子類,通過CAS自旋實作原子操作的更新,悲觀鎖通常都是synchronized和Lock實作,那么MySQL中的樂觀鎖和悲觀鎖又為何呢?
樂觀鎖:每次讀資料的時候都認為其他人不會修改,所以不會上鎖,而是在更新的時候去判斷在此期間有沒有其他人更新了資料,可以使用版本號機制,在資料庫中可以通過為資料表增加一個版本號欄位實作,讀取資料時將版本號一同讀出,資料每次更新時對版本號加一,當我們更新的時候,判斷資料庫表對應記錄的當前版本號與第一次取出來的版本號值進行比對,如果值相等,則予以更新,否則認為是過期資料,樂觀鎖適用于多讀的應用型別,可以提高吞吐量,
# 利用版本號進行CAS更新
UPDATE table t SET t.name='Luffy' WHERE t.id = 1 AND version = 678768;
悲觀鎖:每次讀資料的時候都認為別人會修改,所以每次在讀資料的時候都會上鎖,這樣別人想讀這個資料時就會被阻塞,MySQL中就用到了很多這種鎖機制,比如行鎖,表鎖等,讀鎖,寫鎖等,都是在操作之前先上鎖,
上節的S鎖(共享鎖)和X鎖(排它鎖)都是悲觀鎖,
間隙鎖(Gap Lock)和Next-Key Lock
InnoDB有三種行鎖的演算法:
- Record Lock:單個記錄上的鎖,
- Gap Lock:間隙鎖,鎖定一個索引范圍,但不包含記錄本身,
- Next-Key Lock:Gap Lock + Record Lock,鎖定一個索引范圍,并且包含記錄本身,
間隙鎖使得InnoDB解決幻讀問題,加上MVCC使得InnoDB的RR隔離級別實作了串行化級別的效果,并且保留了比較好的并發性能,
定義:當我們用范圍條件檢索資料時請求共享或排他鎖時,InnoDB會給符合條件的已有資料的索引加鎖;對于鍵值在條件范圍內但表中并不存在的記錄,叫做間隙(GAP),InnoDB也會對這個"間隙"加鎖,這種鎖機制就是間隙鎖,
例如:table表中存在id 1-80,90-99的記錄,SELECT * FROM table WHERE id < 100 FOR UPDATE,InnoDB不僅會對id值為1-80,90-99的記錄加鎖,也會對id在81-89之間(這些記錄并不存在)的間隙加鎖,這樣就能避免事務隔離級別為可重復讀下的幻讀,
死鎖
概念:兩個或兩個以上的事務在執行程序中,因爭奪資源而造成的一種互相等待的現象,
存在條件:1、 互斥條件:一個資源每次只能被一個事務使用,2、 請求與保持條件:一個事務因請求資源而阻塞時,對已獲得的資源保持不放,3、不剝奪條件:已獲得的資源,在末使用完之前不能強行剝奪,4、回圈等待條件:形成一種頭尾相接的回圈等待關系,
解除正在死鎖的狀態:撤銷其中一個事務,
手寫一段死鎖代碼:
T1:
begin;
select * from user u where u.id=1 for update;
update user u set u.name='Carson' where id=2;
T2:
begin;
delete from user u where u.id=2;
delete from user u where u.id=1;
多版本并發控制(MVCC)
- 它使得InnoDB不再單純的使用行鎖來進行資料庫的并發控制,取而代之的是把資料庫的行鎖與行的多個版本結合起來,只需要很小的開銷,就可以實作非鎖定讀,從而大大提高資料庫系統的并發性能,
- 實作:InnoDB實作MVCC的方法是它為每一行存盤三個額外的隱藏欄位:
- DB_TRX_ID:一個6byte的標識,每處理一個事務,其值自動+1 ,可以通過陳述句“show engine innodb status”來查找,
- DB_ROLL_PTR: 大小是7byte,指向寫到rollback segment(回滾段)的一條undo log記錄,
- DB_ROW_ID: 大小是6byte,該值隨新行插入單調增加,
- SELECT:回傳的行資料需要滿足的條件: 1、資料行的創建版本號必須小于等于事務的版本2、行的洗掉版本號(行中的特殊位被設定為將其標記為已洗掉)一定是未定義的或者大于當前事務的版本號,確定了當前事務開始之前行沒有被洗掉,
- INSERT:InnoDB為每個新增行記錄當前系統版本號作為創建版本號,
- DELETE:InnoDB為每個洗掉行的記錄當前系統版本號作為行的洗掉版本號,
- UPDATE:InnoDB復制了一條資料,這條資料的版本號使用了系統版本號,它也把系統版本號作為老資料的洗掉號,
- 說明:這里的讀是不加鎖的SELECT等,MVCC實作可重復讀使用的是讀取undo中的已經提交的資料,是非阻塞的,INSERT操作時"創建時間"=DB_ROW_ID,這時"洗掉時間"是未定義的;UPDATE時,復制新增行的"創建時間"=DB_ROW_ID,洗掉時間未定義,舊資料行"創建時間"不變,洗掉時間=該事務的DB_ROW_ID,DELETE操作,相應資料行的"創建時間"不變,洗掉時間=該事務的DB_ROW_ID;
小結
本篇重點介紹了MySQL的各種鎖機制,熟練其概念及在開發中正確使用是很有必要的,
我是少俠露飛,愛技術,愛分享,
祝大家國慶快樂!
轉載請註明出處,本文鏈接:https://www.uj5u.com/ruanti/157502.html
標籤:其他
