共用鎖(Shared Lock)
共用鎖、S鎖、讀鎖 ,都是他的叫法。
而我,喜歡叫他 共用讀鎖 。
A shared (S) lock permits the transaction that holds the lock to read 。
共用鎖允許持有該鎖的事務讀取。
這裡的共用是, 讀讀共用 。
也就是說, 無論是 行級或是表級 , 如果 對某資料 上了 共用讀鎖 ,其他事務可以繼續 讀(也就是允許持有共用讀鎖), 但是 不能寫,也就是 讀寫互斥。
順便介紹一下如何 加 共用鎖(共用讀鎖) :
上表級共用鎖,也就是表級共用讀鎖:
select * from table(表) lock in share mode ;
上行級共用鎖,也就是行級共用讀鎖:
select * from table(表)where id = 10 lock in share mode ;
在這囉唆一點, 注意了,在InnoDB 下, 不是你想用行鎖就用行鎖的,行鎖的觸發條件我們再次回顧下(開篇有提到):
排他鎖(Exclusive Lock)
排他鎖 、寫鎖、X鎖 ,都是他的叫法。
而我,喜歡叫他 獨佔寫鎖。
An exclusive (X) lock permits the transaction that holds the lock to update or delete。
獨佔(X)鎖允許持有鎖的事務更新或刪除。
獨佔 ,這個詞。 打過籃球沒,以前初中打籃球不懂事,拿著球就不傳。同學就說我,你好獨啊。
是的,我很獨。 就跟這個獨佔寫鎖 (排他鎖) 一樣,很獨。
當事務對某資料加上了 獨佔寫鎖 (排他鎖) ,只有當前事務能夠對這資料執行修改或刪除操作。
其他事務,不能讀,不能寫 。 因為 這個鎖 很獨, 必須等這個很獨 的鎖 使用完了(釋放),其他事務才有機可乘。
所以,獨佔寫鎖 (排他鎖) 是,讀寫互斥、寫寫互斥的。
順便介紹一下如何 加 排他鎖(獨佔寫鎖) :
上表級排他鎖,也就是表級獨佔寫鎖:
select * from table for update ;
上行級排他鎖,也就是行級獨佔寫鎖:
select * from table where id =10 for update ;
在這我再再囉唆一點, 注意了,在InnoDB 下, 不是你想用行鎖就用行鎖的,行鎖的觸發條件我們再次回顧下(開篇有提到):
上面的sql能上行級排他鎖,是因為命中了索引, id 是 索引。
也許看到這裡,你對 共用鎖 & 排他鎖還只是雲裡霧裡 ,大致知道個什麼讀讀共用、讀寫互斥、寫寫互斥啥的。
所以,我們需要再次 從上帝視角再看一次 這兩個鎖 ,
紅色 事務操作一
藍色 事務操作二
共用鎖(共用讀鎖) | 排他鎖(獨佔寫鎖) | |
共用鎖(共用讀鎖) | 可以,相容,一起讀 | 不可以,不相容,想寫得等共用鎖沒了 |
排他鎖(獨佔寫鎖) | 不可以,不相容,上了排他鎖,別人啥都不能動 | 不可以,不相容,上了排他鎖,別人啥都不能動 |
那麼如果你看到這裡,還是對 共用鎖 & 排他鎖還只是雲裡霧裡。
那我只有動手了!
實戰介紹,演示 所謂的讀讀共用、讀寫互斥、寫寫互斥 。
在演示讀讀共用、讀寫互斥、寫寫互斥前, 我必須點明一點!
在這篇文章裡面,我介紹了一些上 共用鎖(共用讀鎖)、排他鎖(獨佔寫鎖)的方式 。 但是 可以看到寫的查詢sql 都是後面加了東西的 , lock in share mode ,for update .... 等。
所以我想點明的一點是,
就好像平時我們經常寫的
select * from table ;
select * from table where age=18;
而排他鎖,除了 select .... for update ,InnoDB引擎 預設的修改 、插入、刪除(update,insert,delete)都是會給操作的相關資料 加 排他鎖的 .
廢話不多說,我們上才藝:
準備一些用於測試的資料。
建表:
DROP TABLE IF EXISTS `user`; CREATE TABLE `user` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL, `age` int(11) NULL DEFAULT NULL, `sex` tinyint(1) NULL DEFAULT NULL, PRIMARY KEY (`id`) USING BTREE ) ENGINE = InnoDB AUTO_INCREMENT = 5 CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Dynamic; SET FOREIGN_KEY_CHECKS = 1;
搞點模擬資料:
(id主鍵索引)
我們不廢話,我們直接上共用讀鎖, 看看是不是能 符合剛才我們的理論 讀讀共用,讀寫互斥!
1. 我們先給id=3這資料上個 共用讀鎖:
2.基於當前狀況, 我們再執行一下查詢語句,也是使用共用讀鎖的:
3.那麼也是基於當前情況,我們再執行一下使用排他寫鎖的查詢語句,可以發現 讀寫互斥了:
4.驗證下,我們檢視當前是否存在事務在等待鎖:
可以從結果中看出 事務請求id 34847在等待鎖:
我們再查詢一下,那些事務在使用鎖,
可以從結果看出,34844事務在使用S鎖,也就是共用讀鎖;
而34847事務 在使用 X鎖, 也就是排他寫鎖(但是由於共用讀鎖先上了,所以讀寫互斥了),所以造成了34847事務 在等待鎖。
5.那麼如果我們一直不 COMMIT 共用讀鎖, 34847事務 會永無止息地等待鎖嗎? 那麼肯定是不可能允許這種一直等待的場景的:
所以mysql會有個等待鎖資源超時的機制,這種情況就會直接返回查詢失敗的結果。
當某資料上了 共用讀鎖 S 時, 只允許其他事務上共用讀鎖 S, 因為讀讀共用;
不允許其他事務上 獨佔寫鎖 X(除非把這個共用讀鎖S 釋放掉),因為讀寫互斥。
1.我們直接給某行資料上個排他寫鎖 X (注意我們的事務是沒有執行COMMIT的) :
2. 我們接下來去 通過共用讀鎖去獲取資料,看看會發生什麼?
這就是 獨佔寫鎖 X 的 讀寫互斥、寫寫互斥 (寫寫互斥的場景就不展示了).
再驗證下,我們看下是不是存在事務在等待鎖資源:
3.那麼如果獨佔寫鎖一直不釋放,其餘事務時一直等待嗎?
也是一樣,會等待超時返回查詢失敗:
補充一個小實踐:
1. 還是一樣,先給某個資料上 獨佔寫鎖,不COMMIT:
2. 執行普通的查詢,select :
可以看到,普通的select語句能正常獲取,為什麼? 因為前面我們提到了:
所以我必須再囉唆一下,所謂的 讀讀共用,讀寫互斥,寫寫互斥 ,都是對於鎖資源來說的,如果你都沒有鎖資源競爭,那肯定不存在什麼互斥什麼互斥了。
推薦學習:
以上就是範例講解MySQL與InnoDB下共用鎖與排他鎖的詳細內容,更多請關注TW511.COM其它相關文章!