MySQL-锁机制

本文探讨了解决并发访问资源时可能出现的脏读、不可重复读、幻读问题的两种策略。方案一采用多版本并发控制(MVCC),在读写操作间实现非阻塞,适合读多写少的场景;方案二则是读写皆加锁,确保数据一致性但可能影响性能。还介绍了锁的内部结构,包括事务信息、索引信息和锁类型等关键元素。
摘要由CSDN通过智能技术生成

协调并发访问某一资源的机制。

一、并发问题的解决方案

如何解决脏读、不可重复读、幻读的问题?

1、方案一:读操作利用多版本并发控制,写操作进行加锁

生成一个ReadView,通过ReadView找到符合条件的记录版本。查询语句只能读到在生成ReadView之前已提交事务所做的更改,在生成ReadView之前未提交的事务或者之后才开启的事务所做的更改是看不到的。而写操作肯定针对的是最新版本的记录,读操作的历史版本和改动记录的最新版本本身并不冲突,也就是采用mvcc时,读-写操作并不冲突。

普通的select语句在read commited和repeatable read隔离级别下会使用到MVCC读取记录。

在read committed 隔离级别下,一个事务在执行过程中每次执行select操作时会生成一个ReadView,ReadView存在的本身就保证了事务不可以读取到未提交的事务所做的更改,也就避免了脏读现象;

在repeatable read隔离级别下,一个事务在执行过程中只有第一次执行select操作才会生成一个ReadView,之后的select复用这个ReadView,这样可以避免幻读和不可重复读的问题。

2、方案二:读写操作都采用加锁的方式

读写操作需要排队执行吗,影响性能。

二、锁的不同角度分类

  • 锁监控
show status like 'innodb_row_lock%'

二、锁的内部结构

  • 锁所在的事务信息:指针,通过指针找到内存中关于该事务的更多信息,例如事务的Id;
  • 索引信息:指针,对于行锁来说,需要记录一下加锁的记录属于哪个索引;
  • 表锁/行锁信息:space id:记录所在表空间,page number:记录所在页号,n_bits:用比特位来区分哪一条记录加锁,在行锁结构的末尾放置了一堆比特位,这个代表使用了多少比特位;
  • type_mode:32位的数,分成了lock_mode,lock_type,rec_lock_type三个部分

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值