這篇文章為大家帶來了關於mysql中共享鎖和排他鎖的相關知識,希望對大家有幫助。
共享鎖定(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影片教學
#以上是實例講解MySQL與InnoDB下共享鎖定與排他鎖的詳細內容。更多資訊請關注PHP中文網其他相關文章!