在并發一致性控制場景中，我們常常用for update悲觀鎖來進行一致性的保證，但是如果不了解它的機制，就進行使用，很容易出現事故，比如for update進行了鎖表導致其他請求只能等待，從而拖垮系統，因此了解它的原理是非常必要的，下面我們通過一系列示例進行測試，來看看到底是什么場景下鎖表什么場景下鎖行。

驗證

1.示例說明

創建一個賬戶表，插入基礎數據，以唯一索引、普通索引、主鍵、普通字段4 個維度進行select ... for update查詢，查看是進行鎖表還是鎖行。

2.表創建

創建一個賬戶表，指定account_no為唯一索引、id為主鍵、user_no為普通字段、curreny為普通索引：

CREATE TABLE `account_info` (
  `id` int NOT NULL AUTO_INCREMENT COMMENT 'ID' ,
 `account_no` int NOT NULL COMMENT '賬戶編號',
 `user_no` varchar(32) NOT NULL COMMENT '用戶 Id',
 `currency` varchar(10) NOT NULL COMMENT '幣種',
  `amount` DECIMAL(10,2) NOT NULL COMMENT '金額',
 `freeze_amount` DECIMAL(10,2) NOT NULL COMMENT '凍結金額',
  `create_time` datetime(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6) COMMENT '創建時間',
  `update_time` datetime(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6) ON UPDATE CURRENT_TIMESTAMP(6) COMMENT '修改時間',
  PRIMARY KEY (`id`) USING BTREE,
 UNIQUE KEY `uni_idx_account_no` (`account_no`) ,
 KEY `idx_currency_` (`currency`) 
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='賬戶信息表';

插入基礎數據：

insert into account_info values (1,1,'ur001','RMB',100,0,now(),now());
insert into account_info values (2,2,'ur002','RMB',1000,0,now(),now());
insert into account_info values (3,3,'ur002','DOLLAR',200,0,now(),now());

3.根據主鍵查詢

在事務 1 中，根據主鍵id=1 進行 for update查詢時，事務2、事務 3 都進行阻塞，而事務 4 由于更新的id=2 所以成功，因此判定，根據主鍵進行 for update 查詢時是行鎖。

4.根據唯一索引查詢

在事務 1 中，根據唯一索引account_no=1 進行 for update查詢時，事務2、事務 3 都進行阻塞，而事務 4 由于更新的account_no=2 所以成功，因此判定，根據唯一索引進行 for update 查詢時是行鎖。

5.根據普通索引查詢

在事務 1 中，根據普通索引currency='RMB' 進行 for update查詢時，事務2、事務 3 都進行阻塞，而事務 4 由于更新的currency='DOLLAR`所以成功，因此判定，根據普通索引進行 for update 查詢時是行鎖。

6.根據普通字段查詢

在事務 1 中，根據普通字段user_no='ur001' 進行 for update查詢時，事務2、事務 3 都進行阻塞，而事務 4查詢的是user_no='ur002'也進行阻塞，因此判定，根據普通字段進行 for update 查詢時是表鎖。

總結

如果查詢條件是索引/主鍵字段，那么select ..... for update會進行行鎖。

如果查詢條件是普通字段(沒有索引/主鍵)，那么select ..... for update會進行鎖表，這點一定要注意。