数据库系列6-锁

事务 锁 索引 日志文件 数据文件 各种buffer flush等概念的串起来

能够解释常见场景下 单个事务和多事务并发场景下,MySQL内部处理机制

在MySQL中,按照锁定的范围,可以分为全局锁、表级锁、行级锁。

全局锁

对MySQL进程中的某个库上锁,上锁的命令FLUSH TABLES WITH READ LOCK;,这是当前数据库处于只读状态,所有会改变数据、表结构等写操作都会被阻塞。试验在只读状态下执行insert操作,返回’Can't execute the query because you have a conflicting read lock‘。(为什么是读锁冲突?)

全局锁的使用场景是备份库,解锁操作UNLOCK TABLES;

当然备份过程中,肯定是要保证数据不会变更的,不然会导致,课程中说的加入一个购买流程,包括添加课程和扣款两个操作,如果不加全局锁,在备份的时候就可能出现只会读到其中一个操作的数据,这就导致了数据错乱?

你可能会问,这两个操作不应该是在同一个事务中的吗,如果只执行了一个动作,说明事务还未提交,你肯定还看不到更新呀。这个逻辑我觉得有一定的道理,但假如这是由两个服务操作的,也就是分布式事务的场景下,当前表的操作肯定先提交了。所以就能读到了。

在备份数据时使用全局锁,不能再写入了,那服务就得停摆,并且作为从库时,也不能及时同步主库过来的binlog了。所以这种方式的成本很高。基于这个原因,我们可以选用另一种方案,将dump操作放在一个可重复读的事务中,利用innodb的mvvc机制,就保证了不会读到中间状态的数据了。

表级锁

表级锁有两种,一是表锁,二是元数据锁(Meta Data Lock)。

表锁的语法:lock tables xxx read;或者lock tables xxx write;。解锁的语法unlock tables;

关于MDL,从级别来讲也是表级的,锁住的当前标的结构定义,MDL是系统自动添加和释放的,DML也分读和写两种。只有读读是共享的,当加了MDL锁(读或者写),DDL会被阻塞。

行锁

行锁是InnoDB特有的,能实现更细粒度的并发控制,这也是InnoDB取代MySQL原生存储引擎MyISAM 的一个原因。在InnoDB事务中,行锁是在需要的时候才加上的,但并不是不需要了就立刻释 放,而是要等到事务结束时才释放。这个就是两阶段锁协议 。

关于锁的问题,因为锁的释放是在事务结束后才会释放的,如果一个事务获得了锁A,执行完毕后,需要再次获得锁B,同时另一个事务,已经获得了锁B,执行完后,想要获得锁A。这时就会出现死锁。

当然死锁对业务来说是无损的,因为MySQL定义了获取锁的超时时间,默认是50s。如果超时,事务立即回滚,对业务无损。但是这个时间太长,并且也没有什么依据来计算一个合理的超时时间。所以在业务开发过程中,可以考虑将需要被频繁获取锁的操作尽量放在事务的最后执行,这样可以尽量减少当前事务对这个锁的持有时间。

另外一种方案,将热点行分成多条数据。

问题:当事务执行更新操作时,MySQL到底选择是行锁还是表锁。其实结合MySQL查找数据的机制来看,当定位数据走了索引,就会对这一行或多行添加行锁,否则,因为指定在主键索引中从头遍历,所以只能用表锁。

所谓的行锁,本质上在锁什么 在锁索引?

意向锁 intention lock

“加锁”操作,本质上也会存在并发操作,怎么保证一个锁完整地被某个事务获取呢,在redis中,setnx

间隙锁 gap lock

next row lock

乐观锁与悲观锁

是在使用锁控制资源竞争的前提下,再次提高并发能力。

所谓的悲观锁,则认为从”我“读到我再写的过程中,一定会有其他事务读写,所以从读到写整个过程我都加锁。

所谓乐观锁,则认为从”我“读到我再写的过程中,大部分情况下并没有其他事务读写,所以读的时候不再加锁,等写的时候,校验一把数据是否还是我当时读出来的样子,如果是,则表示是真没有其他事务在读写,那我就愉快滴把新数据写入。这样我的读写过程遍享受到了不加锁的顺滑。但假如在我写的时候真有其他事务已经谢过了,那我再重新读一遍并重新计算要写入的数据,一直重复这个过程,直至写入数据成功。

按照实际使用场景,真正存在并发的时刻确实不是100%,所以乐观锁的优势就体现出来了。

延伸:

悲观锁、乐观锁其实根据实际场景提出的一种锁优化思想,这个思想在其他地方也有运用,比如Java中的自旋+CAS,就是乐观锁的一种实现。比不管三七二十一,进来先通过synchronized获取锁要高效多。本质思想,尽可能减少不必要的加锁操作

你可能感兴趣的:(数据库系列6-锁)