当前位置：首页 > 文章列表 > 数据库 > MySQL > 浅析MySQL二段锁

浅析MySQL二段锁

来源：SegmentFault 2023-02-16 15:27:11 0浏览收藏

本篇文章主要是结合我之前面试的各种经历和实战开发中遇到的问题解决经验整理的，希望这篇《浅析MySQL二段锁》对你有很大帮助！欢迎收藏，分享给更多的需要的朋友学习~

背景

虽然两阶段加锁（2PL）听起来和两阶段提交（two-phase commit, 2PC）很相似，但它们是完全不同的东西。

在介绍

MySQL二段锁

之前，我需要理清一下概念，即

MySQL

二阶段加锁与二阶段提交的区别：

二阶段加锁：用于单机事务中的一致性和隔离性
二阶段提交：用于分布式事务

何为二段锁

在一个事务操作中，分为

加锁阶段

和

解锁阶段

，且所有的加锁操作在解锁操作之前，具体如下图所示：

加锁时机

当对记录进行更新操作或者

select for update(X锁)、lock in share mode(S锁)

时，会对记录进行加锁，锁的种类很多，不在此赘述。

何时解锁

在一个事务中，只有在

commit

或者

rollback

时，才是解锁阶段。

二阶段加锁最佳实践

下面举个具体的例子，来讲述二段锁对应用性能的影响，我们举个库存扣减的例子：

方案一：
start transaction;
// 锁定用户账户表
select * from t_accout where acount_id=234 for update
//生成订单
insert into t_trans;
// 减库存
update t_inventory set num=num-3 where id=${id} and num>=3;
commit;

方案二：
start transaction;
// 减库存
update t_inventory set num=num-3 where id=${id} and num>=3;
// 锁定用户账户表
select * from t_accout where acount_id=234 for update
//生成订单
insert into t_trans;
commit;

我们的应用通过

JDBC

操作数据库时，底层本质上还是走

TCP

进行通信，

MySQL协议

是一种

停-等式协议

(和

http

协议类似，每发送完一个分组就停止发送，等待对方的确认,在收到确认后再发送下一个分组)，既然通过网络进行通信，就必然会有延迟，两种方案的网络通信时序图如下：

由于商品库存往往是最致命的热点，是整个服务的热点。如果采用第一种方案的话，

TPS

理论上可以提升

3rt/rt=3

倍。而这是在一个事务中只有3条SQL的情况，理论上多一条SQL就多一个rt时间。

另外，当更新操作到达数据库的那个点，才算加锁成功。

commit

到达数据库的时候才算解锁成功。所以，更新操作的前半个

rt

和

commit

操作的后半个

rt

都不计算在整个锁库存的时间内。

性能优化

从上面的例子可以看出，在一个事务操作中，将对最热点记录的操作放到事务的最后面，这样可以显著地提高服务的

吞吐量

。

select for update 和 update where的最优选择

我们可以将一些简单的判断逻辑写到update操作的谓词里面，这样可以减少加锁的时间，如下：

方案一：
start transaction
num = select count from t_inventory where id=234 for update
if count >= 3:
    update t_inventory set num=num-3 where id=234
    commit 
else:
    rollback

方案二：

start transaction:
    int affectedRows = update t_inventory set num=num-3 where id=234 and num>=3
    if affectedRows > 0:
        commit
    else:
        rollback

延时图如下：