按锁的粒度划分
分为:行锁、页锁、表锁
锁定的粒度越小,发生锁冲突的概率越低,可以实现的并发度越高 ;但是对于锁的开销比较大,加锁会比较慢,容易出现死锁。
行锁的三种类型
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;
复制代码
从程序员的角度区分
可以将锁划分为乐观锁和悲观锁。
乐观锁
乐观锁认为对同一数据的并发操作不会总发生,持乐观态度,属于小概率事件;
不需要每次都对数据上锁,也就是不采用数据库自身的锁机制,而是通过程序来实现;
在程序上,我们可以采用版本号机制或者时间戳机制来实现; 其实就是程序层面控制
不会存在死锁的问题,但是阻止不了程序之外的数据库操作。
主要的实现方式:
版本号机制
新增version字段,第一次读取的时候会获取version的值,然后对数据进行更新和删除操作时,会进行版本号的比对;
如果版本号一致,则修改数据,并将版本号+1;如果版本号不一致 则修改失败。
时间戳机制
其道理和版本号一样。
悲观锁
实际上是一种思想,对数据被其他的事务修改持保守态度 会通过数据库自身的锁机制来实现,保证数据操作的排他性!
对数据冲突持有悲观的态度,则认为肯定会冲突,那么在每次数据读取的时候将数据锁住;之后所有的操作读取操作都需要等待;
数据库层面实现,阻止一切数据库操作。
常见的死锁问题
必要条件:互斥,占有且等待,不可强占用,循环等待。
解决死锁的方法
最佳方式就是防止死锁的发生。
注意的一些细节:
不要将无关的操作放进事务里,小事务发生死锁的概率很低;
如果不同的程序会同时操作多个表,应尽量约定以相同的顺序来访问表,这样事务就会形成良好的定义的查询;
尽量按照索引去查数据,范围查找增加了锁的可能性;
对于非常容易产生死锁的业务部分,可以尝试升级锁的粒度;
更新表时,尽量使用主键更新;
设置锁等待超时参数,通过设置 innodblockwait_timeout 参数,设置合理的等待阈值;在高并发的业务中,尽量将该值设置的小一点,避免大量事务等待,占用系统资源,造成严重的性能开销;
Innodb提供了wait-for graph算法来主动进行死锁检测,我们可以通过innodbdeadlockdetect = on 打开死锁检测。
感谢您的阅读,如果对您有帮助,欢迎关注"CRMEB"掘金号。码云上有我们开源的商城项目,知识付费项目,均是基于PHP+vue+mysql开发,学习研究欢迎使用,关注我们保持联系!