数据库—锁以及死锁的处理

锁分类：

参见：https://www.cnblogs.com/zhoading/p/8547320.html

---

 

锁的作用：

• 数据库是一个多用户共享的资源，当出现并发的时候就会出现脏读，数据丢失等问题。所以数据库并发需要使用事务来控制，事务并发问题需要数据库锁来控制，所以数据库锁是跟并发控制和事务联系在一起的。

---

 

事务特性：

ACID（原子性，一致性，隔离性，持久性）四特性，事务是恢复和并发控制的基本单位。

• 原子性指的是事务是数据库的逻辑工作单位，事务中操作要么都做，要么都不做；
• 一致性指的是事务的执行结果必须是使数据库从一个一致性状态变大另一个一致性状态，一致性和原子性是密切相关的；
• 隔离性指的是一个事务执行不能被其他事务干扰；
• 持久性指的是一个事务一旦提交，他对数据库中数据的改变就是永久性的。

---

 

并发控制一般采用三种方法：

1.乐观锁

　　乐观锁认为一个用户读数据的时候，别人不会去写自己所读的数据，所以不做控制。乐观锁是基于系统存储逻辑，限制较大，可能会引起脏读等情况，得根据实际情况灵活运用（在存储过程，函数使用）。

2.悲观锁

　　悲观锁就刚好相反，觉得自己读数据库的时候，别人可能刚好在写自己刚读的数据。所以在读取数据的时候，为了不让别人修改自己读取的数据，就会先对自己读取的数据加锁，只有自己把数据读完事务提交了，才允许别人修改那部分数据。

　　悲观锁可分为共享锁（读锁）和排它锁（写锁），默认来说，当sql脚本修改更新某条记录的时候，会给该条记录加排他锁，读的话加的是共享锁。

• 排它锁：事务设置排它锁后，该事务单独获得此资源，另一事务不能在此事务提交之前获得相同对象的共享锁或排它锁。
• 共享锁：使一个事务对特定数据库资源进行共享访问——另一事务也可对此资源进行访问或获得相同共享锁。

3.时间戳

　　时间戳就是不加锁，通过时间戳来控制并发出现的问题。时间戳就是在数据库表中单独加一列时间字段，每次读出来的时候，把该字段也读出来，当写回去的时候，把该字段加1，提交之前 ，跟数据库的该字段比较一次，如果比数据库的值大的话，就允许保存，否则不允许保存，这种处理方法虽然不使用数据库系统提供的锁机制，但是这种方法可以大大提高数据库处理的并发量，因为这种方法可以避免了长事务中的数据库加锁开销（操作员A 和操作员B操作过程中，都没有对数据库数据加锁），大大提升了大并发量下的系 统整体性能表现。但是操作员操作过程中可能会出现数据提交不了的情况，实际业务中限制较大。

 

死锁及死锁的处理

死锁在操作系统中指的是两个或两个以上的进程在执行的过程中，因争夺资源而造成的一种互相等待的现象，若无外力作用，它们都将无法推进下去。此时称系统处于死锁状态或者系统产生了死锁，这些永远在互相等待的进程称为死锁进程。

 

的死锁原因与解决方案

1. 事务之间对资源访问顺序的交替

出现原因： 
一个用户A 访问表A（锁住了表A），然后又访问表B；另一个用户B 访问表B（锁住了表B），然后企图访问表A；这时用户A由于用户B已经锁住表B，它必须等待用户B释放表B才能继续，同样用户B要等用户A释放表A才能继续，这就死锁就产生了。

解决方法： 
这种死锁比较常见，是由于程序的BUG产生的，除了调整的程序的逻辑没有其它的办法。仔细分析程序的逻辑，对于数据库的多表操作时，尽量按照相同的顺序进行处理，尽量避免同时锁定两个资源，如操作A和B两张表时，总是按先A后B的顺序处理， 必须同时锁定两个资源时，要保证在任何时刻都应该按照相同的顺序来锁定资源

2. 并发修改同一记录

出现原因：主要是由于没有一次性申请够权限的锁导致的。参考：记录一次死锁排查过程

用户A查询一条纪录，然后修改该条纪录；这时用户B修改该条纪录，这时用户A的事务里锁的性质由查询的共享锁企图上升到独占锁，而用户B里的独占锁由于A有共享锁存在所以必须等A释放掉共享锁，而A由于B的独占锁而无法上升的独占锁也就不可能释放共享锁，于是出现了死锁。这种死锁比较隐蔽，但在稍大点的项目中经常发生。 

解决方法：

a. 乐观锁，实现写-写并发

b. 悲观锁：使用悲观锁进行控制。悲观锁大多数情况下依靠数据库的锁机制实现，如Oracle的Select … for update语句，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。

3. 索引不当导致的死锁

出现原因： 
如果在事务中执行了一条不满足条件的语句，执行全表扫描，把行级锁上升为表级锁，多个这样的事务执行后，就很容易产生死锁和阻塞。类似的情况还有当表中的数据量非常庞大而索引建的过少或不合适的时候，使得经常发生全表扫描，最终应用系统会越来越慢，最终发生阻塞或死锁。

另外一种情况是由于二级索引的存在，上锁的顺序不同导致的，这部分在讨论索引时会提到。参考：https://www.cnblogs.com/LBSer/p/5183300.html

解决方法：

SQL语句中不要使用太复杂的关联多表的查询；使用“执行计划”对SQL语句进行分析，对于有全表扫描的SQL语句，建立相应的索引进行优化。

那么，如何尽可能的避免死锁呢？

1）以固定的顺序访问表和行。即按顺序申请锁，这样就不会造成互相等待的场面。

2）大事务拆小。大事务更倾向于死锁，如果业务允许，将大事务拆小。

3）在同一个事务中，尽可能做到一次锁定所需要的所有资源，减少死锁概率。

4）降低隔离级别。如果业务允许，将隔离级别调低也是较好的选择，比如将隔离级别从RR调整为RC，可以避免掉很多因为gap锁造成的死锁。

5）为表添加合理的索引。如果不走索引将会为表的每一行记录添加上锁，死锁的概率大大增大。