阅读 42

mysql锁

表结构分类

行锁

默认情况下,是不需要锁的,默认是开启MVCC机制的,所以读取数据和修改数据完全不会互相影响,直接根据undolog版本链和ReadView来进行读取即可

共享锁

共享锁又被称为S锁

默认查询数据不会开启共享锁的,是走mvcc机制读快照版本,但是可以手动添加

#加共享锁
select * from vpm_project lock in share mode
#查询之后还是更新,这样就给查询语句加上了独占锁
select * from vpm_project for update
复制代码

生产情况下,是不会开启共享锁的,因为根据这样会造成性能下降,而且根据mvcc机制读快也可以保证数据的准确性

如果非要在查询的时候加锁,通常都是在redis/zookeeper分布式锁来控制系统的锁逻辑,因为你如果直接在数据中加上复杂业务的锁逻辑,锁逻辑会隐藏在sql语句中,这对于java来说不太好维护

lock in share mode 只锁覆盖索引

独占锁

默认更新数据的时候是开启的

关系

读取数据其实就是 select

修改数据其实就是 update delete insert

间隙锁

gap lock 官方称为 LOCK_GAP

作用:只是为了给这条记录前面的间隙插入数据

这个锁的设计之初就是为了防止插入幻影记录

这个锁也有S锁和X锁两种,但是其实并没有什么卵用,并不妨碍其他事务的插入

infimum:表示一个表中的最小记录

supremum:表是一个表中的最大记录

比如你要防止在id为20之后中插入新的记录,你就可以给所在页面的supremum加上一个gap锁

Next-Key Lock

作用:既想要给当前记录加锁,又想要阻止其他事务在该记录前面的间隙插入新纪录

本质就是record lock和gap lock的个体

  • 这个锁只有在可重读的情况下才会生效,在可重复读的情况下,mysql加锁的基本单位就是next-key lock
  • next-key lock 是前开后闭区间

insert intention lock

插入意向锁 官方名称为 LOCK_INSERT_INTENTION

一个事务在插入一条记录的时候,需要判断插入位置是否已经被别的事务加入了gap锁,如果有的话,插入操作需要等待,知道等待拥有gap锁的按个事务提交为止。

innodb规定,这种也需要生成一个锁,于是命名为insert intention lock

这个锁比较“鸡肋”,不会阻拦任何其他事务的操作

record lock

我们自己给它起个别名叫 记录锁 官方 名称为 LOCK_REC_NOT_GAP

就是给数据库里的一条记录加锁,这中锁也有S锁和X锁两种

和基础的S锁和X锁一样

写锁和写锁 读锁都冲突

读锁和读锁不冲突,和写锁冲突

隐式锁

事务id其实就是一个隐式锁

其他所有的锁,加锁之后都会在内存中创建一个锁记录关联,只有隐式锁不会

两段锁协议

在 InnoDB 事务中,行锁是在需要的时候才加上的,但并不是不需要了就立刻释放,而是要等到事务结束时才释放。这个就是两阶段锁协议。

如果你的事务中需要锁多个行,要把最可能造成锁冲突、最可能影响并发度的锁尽量往后放。

出现死锁之后的解决办法:

  • 一种策略是,直接进入等待,直到超时。这个超时时间可以通过参数 innodb_lock_wait_timeout 来设置。
  • 另一种策略是,发起死锁检测,发现死锁后,主动回滚死锁链条中的某一个事务,让其他事务得以继续执行。将参数 innodb_deadlock_detect 设置为 on,表示开启这个逻辑。

如何解决热点行更新导致的性能问题?

  1. 如果你能确保这个业务一定不会出现死锁,可以临时把死锁检测关闭掉。一般不建议采用
  2. 控制并发度,对应相同行的更新,在进入引擎之前排队。这样在InnoDB内部就不会有大量的死锁检测工作了。
  3. 将热更新的行数据拆分成逻辑上的多行来减少锁冲突,但是业务复杂度可能会大大提高。

表锁

执行DDL语句的时候,默认会加上表锁,这是通过数据库的元数据锁实现的,也就是Metadata Locks

DDL语句和增删改操作,确实是互斥的

共享锁

#加表级共享锁
lock tables 表名 read;
复制代码

独占锁

#加表级独占锁
lock tables 表名 write;
复制代码

意向共享锁

当有事务在表里执行增删改操作的时候,会默认在行级加独占锁,同时也会在表级加一个意向独占锁

意向独占锁

当有事务在表里执行查询操作的时候,会默认在表级加一个意向共享锁

关系

全局锁

对整个数据库实例加锁。

MySQL提供加全局读锁的方法:Flush tables with read lock(FTWRL)

这个命令可以使整个库处于只读状态。使用该命令之后,数据更新语句、数据定义语句和更新类事务的提交语句等操作都会被阻塞。

使用场景:全库逻辑备份。

风险:

1.如果在主库备份,在备份期间不能更新,业务停摆

2.如果在从库备份,备份期间不能执行主库同步的binlog,导致主从延迟

官方自带的逻辑备份工具mysqldump,当mysqldump使用参数--single-transaction的时候,会启动一个事务,确保拿到一致性视图。而由于MVCC的支持,这个过程中数据是可以正常更新的。

一致性读是好,但是前提是引擎要支持这个隔离级别。

如果要全库只读,为什么不使用set global readonly=true的方式?

1.在有些系统中,readonly的值会被用来做其他逻辑,比如判断主备库。所以修改global变量的方式影响太大。

2.在异常处理机制上有差异。如果执行FTWRL命令之后由于客户端发生异常断开,那么MySQL会自动释放这个全局锁,整个库回到可以正常更新的状态。而将整个库设置为readonly之后,如果客户端发生异常,则数据库就会一直保持readonly状态,这样会导致整个库长时间处于不可写状态,风险较高。

加锁条件

  • 在同一个事务中进行加锁操作
  • 被加锁的记录在同一个页面中
  • 加锁的类型是一样的】
  • 等待状态是一样的

同时满足上面四个条件,就可以将多个所记录的锁放在同一个锁结构中

加锁规则总结

可重复读

  • 加锁的基本单位是 next-key lock。希望你还记得,next-key lock 是前开后闭区间。
  • 查找过程中访问到的对象才会加锁。
  • 等值查询,给唯一索引加锁的时候,next-key lock 退化为行锁。如果不是唯一索引,向右遍历时且最后一个值不满足等值条件的时候,next-key lock 退化为间隙锁。
  • 范围查询,无论是否是唯一索引,范围查询都需要访问到不满足条件的第一个值为止
  • for update 默认的是更新之后还要进行查找,所以不仅给索引上锁,符合条件的主键索引页会上锁
  • 唯一索引会找到对应范围就会停止,但是非唯一索引是需要多找一段
  • 范围索引InnoDB 会往前扫描到第一个不满足条件的行为止
  • 删除的时候limit,不仅可以控制删除数据的条数,让操作更安全,还可以减小加锁的范围

读提交

语句执行过程中加上的行锁,在语句执行完成后,就要把“不满足条件的行”上的行锁直接释放了,不需要等到事务提交。

文章分类
后端
文章标签