在并发一致性控制场景中,我们常常用for update悲观锁来进行一致性的保证,但是如果不了解它的机制,就进行使用,很容易出现事故,比如for update进行了锁表导致其他请求只能等待,从而拖垮系统,因此了解它的原理是非常必要的,下面我们通过一系列示例进行测试,来看看到底是什么场景下锁表什么场景下锁行。
验证
1.示例说明
创建一个账户表,插入基础数据,以唯一索引、普通索引、主键、普通字段4 个维度进行select ... for update查询,查看是进行锁表还是锁行。
2.表创建
创建一个账户表,指定account_no为唯一索引、id为主键、user_no为普通字段、curreny为普通索引:
插入基础数据:
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会进行锁表,这点一定要注意。