select...for update到底是加了行鎖，還是表鎖？
前言
前幾天，知識星球中的一個小夥伴，問了我一個問題：在MySQL中，事務A中使用select...for update where id=1鎖住了，某一條資料，事務還沒提交，此時，事務B中去用select ... where id=1查詢那條資料，會阻塞等待嗎？
select...for update在MySQL中，是一種悲觀鎖的用法，一般情況下，會鎖住一行資料，但如果沒有使用正確的話，也會把整張表鎖住。
其實，我之前也在實際專案中試過用，比如：積分兌換禮品的功能。
今天跟大家一起聊聊select...for update這個話題，希望對你會有所幫助。
1. 要什麼要用行鎖？
假如現在有這樣一種業務場景：使用者A給你轉賬了2000元，使用者B給你轉賬了3000元，而你的賬戶初始化金額是1000元。
在事務1中會執行下面這條sql：
update account set money=money+2000
where id=123;
在事務2中執行下面這條sql：
update account set money=money+3000
where id=123;
這兩條sql執行成功之後，你的money可能是：3000、4000、6000，這三種情況中的一種。
你之前的想法是，使用者A和使用者B總共給你轉賬5000，最終你賬戶的錢應該是6000才對，3000和4000是怎麼來的？
假如事務1在執行update語句的過程中，事務2同時也在執行update語句。
事務1中查詢到money是1000，此外事務2也查詢到money是1000。
如果事務1先執行update語句，事務2後執行update語句，第一次update的3000，會被後面的4000覆蓋掉，最終結果為4000。
如果事務2先執行update語句，事務1後執行update語句，第一次update的4000，會被後面的3000覆蓋掉，最終結果為3000。
這兩種情況都產生了嚴重的資料問題。
我們需要有某種機制，保證事務1和事務2要順序執行，不要一起執行。
這就需要加鎖了。
目前MySQL中使用比較多的有：表鎖、行鎖和間隙鎖。
我們這個業務場景，非常時候使用行鎖。
在事務1執行update語句的過程中，先要把某一行資料鎖住，此時，其他的事務必須等待事務1執行完，提交了事務，才能獲取那一行的資料。
在MySQL中是通過select...for update語句來實現的行鎖的功能。
但如果你在實際工作中使用不正確，也容易把整張表鎖住，嚴重影響效能。
select...where...for update語句的用法是否正確，跟where條件中的引數有很大的關係。
我們一起看看下面幾種情況。
假如user表現在有這樣的資料庫，資料庫的版本是：8.0.21。
建立的索引如下：
其中id是主鍵欄位，code是唯一索引欄位，name是普通索引欄位，其他的都是普通欄位。
2. 主鍵
當where條件用的資料庫主鍵時。
例如開啟一個事務1，在事務中更新id=1的使用者的年齡：
begin;
select * from user where id=1 for update;
update user set age=22 where id=1;
where條件中的id是資料庫的主鍵，並且使用for update關鍵字，加了一個行鎖，這個事務沒有commit。
此時，開啟了另外一個事務2，也更新id=1的使用者的年齡：
begin;
update user set age=23 where id=1;
commit;
在執行事務2的sql語句的過程中，會一直等待事務1釋放鎖。
如果事務1一直都不釋放行鎖，事務2最後會報下面這個異常：
如果此時開始一個事務3，更新id=2的使用者的年齡：
begin;
update user set age=23 where id=2;
commit;
執行結果如下：
由於事務3中更新的另外一行資料，因此可以執行成功。
說明使用for update關鍵字，鎖住了主鍵id=1的那一行資料，對其他行的資料並沒有影響。
3. 唯一索引
當where條件用的資料庫唯一索引時。
開啟一個事務1，在事務中更新code=101的使用者的年齡：
begin;
select * from user where code='101' for update;
update user set age=22 where code='101';
where條件中的code是資料庫的唯一索引，並且使用for update關鍵字，加了一個行鎖，這個事務沒有commit。
此時，開啟了另外一個事務2，也更新code=101的使用者的年齡：
begin;
update user set age=23 where code='101';
commit;
執行結果跟主鍵的情況是一樣的。
4. 普通索引
當where條件用的資料庫普通索引時。
開啟一個事務1，在事務中更新name=周星馳的使用者的年齡：
begin;
select * from user where name='周星馳' for update;
update user set age=22 where name='周星馳';
where條件中的name是資料庫的普通索引，並且使用for update關鍵字，加了一個行鎖，這個事務沒有commit。
此時，開啟了另外一個事務2，也更新name=周星馳的使用者的年齡：
begin;
update user set age=23 where name='周星馳';
commit;
執行結果跟主鍵的情況也是一樣的。
5. 主鍵範圍
當where條件用的資料庫主鍵範圍時。
開啟一個事務1，在事務中更新id in (1,2)的使用者的年齡：
begin;
select * from user where id in (1,2) for update;
update user set age=22 where id in (1,2);
where條件中的id是資料庫的主鍵範圍，並且使用for update關鍵字，加了多個行鎖，這個事務沒有commit。
此時，開啟了另外一個事務2，也更新id=1的使用者的年齡：
begin;
update user set age=23 where id=1;
commit;
執行結果跟主鍵的情況也是一樣的。
此時，開啟了另外一個事務2，也更新id=2的使用者的年齡：
begin;
update user set age=23 where id=2;
commit;
執行結果跟主鍵的情況也是一樣的。
6. 普通欄位
當where條件用的資料庫普通欄位時。
該欄位既不是主鍵，也不是索引。
開啟一個事務1，在事務中更新age=22的使用者的年齡：
begin;
select * from user where age=22 for update;
update user set age=22 where age=22 ;
where條件中的age是資料庫的普通欄位，並且使用for update關鍵字，加的是表鎖，這個事務沒有commit。
此時，開啟了另外一個事務2，也更新age=22的使用者的年齡：
begin;
update user set age=23 where age=22 ;
commit;
此時，執行事務2時，會一直阻塞等待事務1釋放鎖。
調整一下sql條件，查詢條件改成age=23：
begin;
update user set age=23 where age=23 ;
commit;
此時，行事務3時，也會一直阻塞等待事務1釋放鎖。
也就是說，在for update語句中，使用普通欄位作為查詢條件時，加的是表鎖，而並非行鎖。
7. 空資料
當where條件查詢的資料不存在時，會發生什麼呢？
開啟一個事務1，在事務中更新id=66的使用者的年齡：
begin;
select * from user where id=66 for update;
update user set age=22 where id=66 ;
這條資料是不存在的。
此時，開啟了另外一個事務2，也更新id=66的使用者的年齡：
begin;
update user set age=23 where id=66 ;
commit;
執行結果：
執行成功了，說明這種情況沒有加鎖。
總結
最後給大家總結一下select...for update加鎖的情況：
- 主鍵欄位：加行鎖。
- 唯一索引欄位：加行鎖。
- 普通索引欄位：加行鎖。
- 主鍵範圍：加多個行鎖。
- 普通欄位：加表鎖。
- 查詢空資料：不加鎖。
如果事務1加了行鎖，一直沒有釋放鎖，事務2操作相同行的資料時，會一直等待直到超時。
如果事務1加了表鎖，一直沒有釋放鎖，事務2不管操作的是哪一行資料，都會一直等待直到超時。
最後說一句(求關注，別白嫖我)
如果這篇文章對您有所幫助，或者有所啟發的話，幫忙掃描下發二維條碼關注一下，您的支援是我堅持寫作最大的動力。
求一鍵三連：點贊、轉發、在看。
關注公眾號：【蘇三說技術】，在公眾號中回覆：面試、程式碼神器、開發手冊、時間管理有超讚的粉絲福利，另外回覆：加群，可以跟很多BAT大廠的前輩交流和學習。
最後歡迎大家加入蘇三的知識星球【Java突擊隊】，一起學習。
星球中有很多獨家的乾貨內容，比如：Java後端學習路線，分享實戰專案，原始碼分析，百萬級系統設計，系統上線的一些坑，MQ專題，真實面試題，每天都會回答大家提出的問題，免費修改簡歷，免費回答工作中的問題。
星球目前開通了9個優質專欄：技術選型、系統設計、踩坑分享、工作實戰、底層原理、Spring原始碼解讀、痛點問題、高頻面試題 和 效能優化。