多個(gè)事務(wù)同時(shí)更新一行數(shù)據(jù)，都會加鎖，然后排隊(duì)等待，必須一個(gè)事務(wù)執(zhí)行完畢提交了，釋放鎖，才能喚醒下一個(gè)事務(wù)繼續(xù)執(zhí)行。那這多個(gè)事務(wù)運(yùn)行時(shí)，加的啥鎖?

是X鎖，Exclude獨(dú)占鎖，當(dāng)有一個(gè)事務(wù)加了獨(dú)占鎖，此時(shí)其他事務(wù)再想更新這行數(shù)據(jù)，都要加獨(dú)占鎖，但只能暫時(shí)生成獨(dú)占鎖并在后面等待。

當(dāng)有人在更新數(shù)據(jù)時(shí)，其他事務(wù)可以讀取這行數(shù)據(jù)嗎?需要加鎖嗎?

不用，因?yàn)槟J(rèn)情況下，有人在更新數(shù)據(jù)時(shí)，然后你要去讀取，直接默認(rèn)就是開啟MVCC。即此時(shí)對一行數(shù)據(jù)的讀、寫兩個(gè)操作默認(rèn)不會加鎖互斥，因?yàn)镸ySQL的MVCC就是為此設(shè)計(jì)，避免頻繁加鎖互斥。

此時(shí)你讀取數(shù)據(jù)，完全可以根據(jù)你的ReadView，去undo log版本鏈條里找個(gè)你能讀的版本，而完全不用顧慮別人是否在更新。

就算你真的等他更新完畢并提交了，基于MVCC，你也讀不到他更新的值!因?yàn)镽eadView機(jī)制不允許，所以你默認(rèn)情況下的讀，完全無需加鎖，不需要去關(guān)心其他事務(wù)的更新加鎖問題，直接基于MVCC讀某個(gè)快照即可。

萬一要是你在執(zhí)行查詢操作時(shí)，偏想加鎖呢?

也可以滿足你，MySQL支持共享鎖，S鎖，語法如下：

select * from table lock in share mode

在查詢語句后面加上lock in share mode，意思就是查詢的時(shí)候?qū)σ恍袛?shù)據(jù)加共享鎖。若此時(shí)有別的事務(wù)在更新這行數(shù)據(jù)，已經(jīng)加了獨(dú)占鎖，此時(shí)你的共享鎖還能加嗎?

若你先加了共享鎖，然后別人來更新要加獨(dú)占鎖行嗎?

當(dāng)然不行了，此時(shí)鎖互斥，他只能等待。

若你在加共享鎖時(shí)，別人也加共享鎖呢?

可以的，你們倆都可加共享鎖，共享鎖和共享鎖不互斥。

所以更新數(shù)據(jù)時(shí)，必然加獨(dú)占鎖，獨(dú)占鎖和獨(dú)占鎖互斥，此時(shí)別人不能更新; 但若此時(shí)你要查詢，默認(rèn)不加鎖，走M(jìn)VCC讀快照版本，但你查詢是可以手動加共享鎖的，共享鎖和獨(dú)占鎖互斥，共享鎖和共享鎖不互斥。

一般開發(fā)業(yè)務(wù)系統(tǒng)的時(shí)候，其實(shí)你查詢主動加共享鎖很少見，數(shù)據(jù)庫行鎖雖然實(shí)用， 但一般不會在數(shù)據(jù)庫層面做復(fù)雜的手動加鎖，反而會用基于redis/zookeeper的分布式鎖來控制業(yè)務(wù)系統(tǒng)的鎖邏輯。

查詢操作還能加互斥鎖：

select * from table for update

我查出來數(shù)據(jù)以后還要更新，此時(shí)我加獨(dú)占鎖了，其他閑雜人等，都不要更新這數(shù)據(jù)了!

一旦你查詢時(shí)加獨(dú)占鎖，在你事務(wù)提交前，任何人都不能更新數(shù)據(jù)，只能你在本事務(wù)里更新數(shù)據(jù)，等你提交了，別人才能再更新數(shù)據(jù)。

總結(jié)

本文描述了默認(rèn)情況下更新數(shù)據(jù)的獨(dú)占鎖，默認(rèn)情況下查詢數(shù)據(jù)的mvcc機(jī)制讀快照，然后通過查詢加共享鎖和獨(dú)占鎖的方式，共享鎖和獨(dú)占鎖之間的互斥規(guī)則。