关于事务并发控制可能出现问题SQL的解决策略

本文探讨了数据库事务并发控制中的问题及其解决方案,重点介绍了不同封锁协议和隔离级别,如一级、二级、三级封锁协议,以及可序列化隔离级别。通过设置合适的隔离级别,可以防止脏读、幻读等问题,更新锁作为一种更宽松的锁策略,避免了死锁的发生。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

在这周的课程中我们学习了事务的并发控制所能解决的问题。

数据库作为一种面向所有授权用户的信息集合,不可避免地出现受到来自不同用户的调用和读写,而不同的时间进行调用和读写会对数据列产生不同的影响。所以数据库引入了不用锁的标准来减少这类问题。也就是隔离级别,不同的隔离级别的统称就是不同的封锁协议。

首先是一级封锁协议,在此协议中只使用排它锁(X lock)。一级协议是三级协议中最简单的一级,是最基础的封锁协议。甚至连脏读都没有办法解决。


然后就是二级协议,二级封锁协议是基于一级封锁协议上的完善,在此协议中仅使用共享锁,但对于释放条件有所改变,可以解决脏读的问题,但是从操作步骤上来说,没有办法解决幻读的问题。这就需要三级封锁协议

三级封锁协议基于二级封锁协议,对释放条件有所改变,从而解决了脏读和幻读的问题。但是没有办法解决对列添加所出现的问题。这时候就需要隔离级别:可序列化(四级封锁协议)来解决这个问题。


如果任务有一个队列,每一个任务都排队,直到完成才能进行下一个任务,这样的工作效率肯定是极其低下的,对于这种问题,可序列化可以解决,所以可序列化也被称作可串行化。

在隔离级别”可序列化“中,将自动在索引上获得范围锁,保护查询读取的行的范围(但不是查询条件所指定的范围),从而确保其它事务不会插入新数据,解决幻读(插入数据);由于封锁范围延伸至查询条件所指定的范围外最近的行,故在查询条件所指定的范围之外的插入亦可能被阻塞。


对于共享锁和排它锁还有一些补充说明,共享锁对于读取数据是允许的,也就是说允许多个用户对同一个数据进行读写,而一个用户在读取另一个用户如果在之后想要进行写入操作,就必须要等待其读写结束后执行,在SQL的操作界面上也有其对应的等待流程。但是排它锁的要求就相对严格,在一个用户读写的时候就禁止另外一个用户读写,如果有两个用户要求对一个表格中的列进行读写,则会发生死锁事件,双方都无法对该列进行读写,这时候SQL会根据请求时间,将其中一个用户作为死锁牺牲品,终止其读写要求,直到之前一个用户的读写要求完成后再开放读写权限。那么除了排它锁之外,有没有要求相对宽松的锁呢。有,更新锁。

更新锁基于排它锁之上条件相对宽松,在两个用户同时进行读写的时候,会阻止一个用户进行读写但不会阻塞共享锁,也就不会发生死锁现象。





评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值