关于数据库锁的总结

本文主要是在总结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 打开死锁检测。