資料庫 鎖的使用

2021-08-28 04:19:48 字數 1809 閱讀 7040

表級鎖:

分類一:讀鎖

lock

table student read;#讀鎖

可執行:select*from student;

等待解鎖:當前不能執行insert,update,delete操作

unlock tables;#解鎖

解鎖後才可以執行insert 操作,update,delete

當我們執行鎖表,使用read 讀鎖,則,在解鎖之前,student表都只能讀取,即只能執行select操作,插入操作insert 都處於等待解鎖的狀態。只能讀,不能寫。

分類二:寫鎖

lock

table balance write; #寫鎖

insert

into balance(`user_id`,`money`)values(7,77);

select * from

`balance`;

#unlock tables;

#insert

into balance(`user_id`,`money`)values(6,44);

注意這裡並沒有解鎖,但是成功插入了。

但是這是在乙個mysql回話中插入的,如果是新的會話insert into語句還是會處於等待狀態,等待這個表解鎖。並且新的回話中也select語句也是如此。

意思是:如果是寫鎖沒有解鎖,新的 會話 讀寫 都處於被鎖狀態。

行級鎖

myisam和innodb都支援表級鎖。

行級鎖只有innodb支援,也是mysql中的最小粒度鎖,也是真正的事務鎖。

共享鎖

行級鎖分為:共享鎖和排它鎖

**#共享鎖**

select *** lock

in share mode;

這樣就開啟了共享鎖,凡是select取出來的行資料只有該回話可以修改,直到commit之後其他回話才能修改,但是過程當中其他會話可以讀取。

行鎖是索引級別的,並不是記錄級別的

start

transaction;#開啟事務

select * from

`balance`

where user_id=3

lock

in share mode;

#commit;提交事務

在新的會話中,可以讀取,但不能修改:

#另乙個會話中

select * from

`balance`

where user_id=3;#可以讀取

update balance set money=99

where user_id=3;#等待狀態

這條語句是修改是user_id=3的條件,那麼user_id=4的條件下能否修改?

發現也不能修改,這是為啥?

因為行鎖是索引級別的,並不是記錄級別的,我們的資料表user_id欄位不是索引字段。

所以這告訴我們:在設定行級鎖的時候,where條件裡的字段應該是索引字段。

排它鎖

select *** for upadte;
開啟了排它鎖,其他會話依然不能修改資料。但是可以普通的讀取。

如果另外乙個會話也想加鎖,則會衝突。

資料庫的鎖

相當好的文章!希望以後結合實踐再好好理解。innodb中的事務隔離級別和鎖的關係 mysql faq 系列 如何檢視當前最新事務id mysql 對於千萬級的大表要怎麼優化?鎖有悲觀鎖和樂觀鎖。悲觀鎖中分共享鎖和排他鎖。在事務中,讀資料的時候加分享鎖 其他事務還可以加分享鎖,但是不能加排他鎖 寫資料...

資料庫的鎖

innodb 除了支援行級鎖,還支援由 mysql 服務層實現的表級鎖 lock tables write在指定的表加上表級排他鎖 當這兩種鎖同時存在時,可能導致衝突。例如,事務 a 獲取了表中一行資料的讀鎖 然後事務 b 申請該錶的寫鎖 例如修改表的結構 如果事務 b 加鎖成功,那麼它就應該能修改...

資料庫的鎖

鎖是用於管理對共享資源的併發訪問,是資料庫系統區別於檔案系統的乙個關鍵特性 本文主要來談innodb引擎,innodb引擎支援行鎖 表鎖粒度的鎖 為了支援多粒度鎖定,innodb 儲存引擎引入了意向鎖 intention lock 意向鎖是表級鎖 什麼是意向鎖呢?如果沒有意向鎖,當已經有人使用行鎖對...