关于数据库锁的总结


前言

本文主要是在总结MySQL数据库锁时,记录的一些笔记。

按锁的粒度划分

分为:行锁、页锁、表锁

锁定的粒度越小,发生锁冲突的概率越低,可以实现的并发度越高 ;但是对于锁的开销比较大,加锁会比较慢,容易出现死锁。

行锁的三种类型

Record Lock 单个记录上的锁

对索引项加锁,如果innodb引擎的表在建立的时候 没有设置任何索引 那么这时候对InnoDB存储引擎会用隐性的主键来进行锁定。

Gap Lock 间隙锁

对索引项之间的间隙加锁,设计目的:为了解决幻读,利用这种锁技术,锁定的不是单个值,而是一个范围。

Next-key lock

则是前面两种的组合,对索引项以其之间的间隙加锁。

只有在可重复读或以上的隔离级别下的特定操作才会取得gap lock或者 next-key lock,在select update delete时,除了基于唯一索引的查询之外,其他索引都会获取gap lock 或者 next-key lock,即锁住扫描的范围。

从数据库的管理角度区分

共享锁和排他锁 ,即读锁和写锁

共享锁

也叫读锁或者S锁。

共享锁的资源可以被其他用户读取,但是不能修改;在select时,会将对象进行共享锁锁定;读取完毕时,就会释放锁,就可以保证数据在读取时不会被修改。

lock table xxx read;

unlock table;

共享锁出现死锁的原因:多个事务对同一数据获得读锁的时候,可能会出现死锁。

排他锁

也叫独占锁,写锁或者X锁。

排它锁,锁定的数据只允许进行锁定的事务使用;其他事务无法对已锁定的数据进行查询和操作。

lock table xxx write;

unlock table;

从程序员的角度区分

可以将锁划分为乐观锁和悲观锁。

乐观锁

乐观锁认为对同一数据的并发操作不会总发生,持乐观态度,属于小概率事件;

不需要每次都对数据上锁,也就是不采用数据库自身的锁机制,而是通过程序来实现;

在程序上,我们可以采用版本号机制或者时间戳机制来实现; 其实就是程序层面控制

不会存在死锁的问题,但是阻止不了程序之外的数据库操作。

主要的实现方式:

1.版本号机制

新增version字段,第一次读取的时候会获取version的值,然后对数据进行更新和删除操作时,会进行版本号的比对;

如果版本号一致,则修改数据,并将版本号+1;如果版本号不一致 则修改失败。

2.时间戳机制

其道理和版本号一样。

悲观锁

实际上是一种思想,对数据被其他的事务修改持保守态度 会通过数据库自身的锁机制来实现,保证数据操作的排他性

对数据冲突持有悲观的态度,则认为肯定会冲突,那么在每次数据读取的时候将数据锁住;之后所有的操作读取操作都需要等待;

数据库层面实现,阻止一切数据库操作。

常见的死锁问题

必要条件:互斥,占有且等待,不可强占用,循环等待。

解决死锁的方法

最佳方式就是防止死锁的发生。

注意的一些细节:

  1. 不要将无关的操作放进事务里,小事务发生死锁的概率很低;

  2. 如果不同的程序会同时操作多个表,应尽量约定以相同的顺序来访问表,这样事务就会形成良好的定义的查询;

  3. 尽量按照索引去查数据,范围查找增加了锁的可能性;

  4. 对于非常容易产生死锁的业务部分,可以尝试升级锁的粒度;

  5. 更新表时,尽量使用主键更新;

  6. 设置锁等待超时参数,通过设置 innodb_lock_wait_timeout 参数,设置合理的等待阈值;在高并发的业务中,尽量将该值设置的小一点,避免大量事务等待,占用系统资源,造成严重的性能开销;

  7. Innodb提供了wait-for graph算法来主动进行死锁检测,我们可以通过innodb_deadlock_detect = on 打开死锁检测。