UPDATE是否會加鎖？

SQL語句為如下時，是否會加鎖？

UPDATE table1 SET num = num + 1 WHERE id=1;

答案是不會

實際上MySQL是支持給數(shù)據(jù)行加鎖（InnoDB）的，并且在UPDATE/DELETE等操作時確實會自動加上排它鎖。只是并非只要有UPDATE關(guān)鍵字就會全程加鎖，針對上面的MySQL語句而言，其實并不只是一條UPDATE語句，而應(yīng)該類似于兩條SQL語句（偽代碼）：

a = SELECT * FROM table1 WHERE id=1;
UPDATE table1 SET num = a.num + 1 WHERE id=1;

其中執(zhí)行SELECT語句時沒有加鎖，只有在執(zhí)行UPDATE時才進行加鎖的。所以才會出現(xiàn)并發(fā)操作時的更新數(shù)據(jù)不一致。原因找到了，解決問題就不遠了。而針對這類問題，解決的方法可以有2種：

• 通過事務(wù)顯式的對SELECT進行加鎖
• 使用樂觀鎖機制

SELECT顯式

加鎖對SELECT進行加鎖的方式有兩種，如下：

SELECT ... LOCK IN SHARE MODE  #共享鎖，其它事務(wù)可讀，不可更新
SELECT ... FOR UPDATE    #排它鎖，其它事務(wù)不可讀寫

如果你不使用這2種語句，默認情況下SELECT語句是不會加鎖的。并且對于上面提到的場景，必須使用排它鎖。另外，上面的2種語句只有在事務(wù)之中才能生效，否則不會生效。在MySQL命令行使用事務(wù)的方式如下：

SET AUTOCOMMIT=0; 
BEGIN WORK; 
 a = SELECT num FROM table1 WHERE id=2 FOR UPDATE; 
 UPDATE table1 SET num = a.num + 1 WHERE id=2; 
COMMIT WORK;

這樣只要以后更新數(shù)據(jù)時，都使用這樣事務(wù)來進行操作；那么在并發(fā)的情況下，后執(zhí)行的事務(wù)就會被堵塞，直到當前事務(wù)執(zhí)行完成。（通過鎖把并發(fā)改成了順序執(zhí)行）

使用樂觀鎖

樂觀鎖是鎖實現(xiàn)的一種機制，它總是會天真的認為所有需要修改的數(shù)據(jù)都不會沖突。所以在更新之前它不會給數(shù)據(jù)加鎖，而只是查詢了數(shù)據(jù)行的版本號（這里的版本號屬于自定義的字段，需要在業(yè)務(wù)表的基礎(chǔ)上額外增加一個字段，每當更新一次就會自增或者更新）。

在具體更新數(shù)據(jù)的時候更新條件中會添加版本號信息，

• 當版本號沒有變化的時候說明該數(shù)據(jù)行未被更新過，并且也滿足更新條件，所以會更新成功。
• 當版本號有變化的時候，則無法更新數(shù)據(jù)行，因為條件不滿足，此時就需要在進行一次SQL操作。（重新查詢記數(shù)據(jù)行，再次使用新的版本號更新數(shù)據(jù)）

實踐

對 for update上鎖進行一次實踐一個student表，其中有一條數(shù)據(jù)

開啟兩個client

第一個開啟事務(wù)后執(zhí)行

select name from student where id = 1 for update;

第二個開啟事務(wù)后執(zhí)行相同的語句，發(fā)現(xiàn)該條數(shù)據(jù)被第一個事務(wù)上鎖阻塞了

這時候第一個事務(wù)執(zhí)行修改并commit；

第二個事務(wù)的select執(zhí)行，發(fā)現(xiàn)阻塞了4秒多

小結(jié)

總的來說，這2種方式都可以支持數(shù)據(jù)庫的并發(fā)更新操作。但具體使用哪一種就得看實際的應(yīng)用場景，應(yīng)用場景對哪種支持更好，并且對性能的影響最小。

以上就是本文的全部內(nèi)容，希望對大家的學習有所幫助，也希望大家多多支持腳本之家。