MySQL中的锁机制

一、锁的分类

1.1 对数据的操作类型分类

• 读锁（共享锁）：针对同一份数据，多个读操作可以同时进行，不会相互影响
• 写锁（排他锁）：当前写操作未完成之前，它会阻断其他的写锁和读锁

1.2 对数据操作的粒度分类

为了尽可能提高数据库并发度，每次锁定的数据范围越小越好，理论上每次只锁定当前操作的数据的方案会得到最大的并发度，但这样锁的数量也会增多，管理锁时比较耗资源的事情。因此数据库系统需要在高并发响应和系统性能两方面进行平衡，这样就产生了锁粒度的概念

• 表锁：开销小，加锁快；不会出现死锁；锁的粒度大，发生锁冲突的概率最高，并发度最低，MyISAM和MEMORY存储引擎采用的是表级锁
• 行锁：开销大，加锁慢；会出现死锁；锁的粒度小，发生锁冲突的概率最低，并发度很高，InnoDB存储引擎即支持表锁也支持行锁，但默认情况下是采用的行锁
• 页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般
  

二、MyISAM表锁

MyISAM的表锁有两种模式：

• 表共享读锁：不会阻塞其他用户对同一表的读请求，但会阻塞对同一表的写请求
• 表独占写锁：会阻塞其他用户对同一表的读和写操作

MyISAM 表的读操作与写操作之间，以及写操作之间是串行的。当一个线程获得对一个表的写锁后， 只有持有锁的线程可以对表进行更新操作。其他线程的读、 写操作都会等待，直到锁被释放为止。

默认情况下，写锁比读锁具有更高的优先级：当一个锁释放时，这个锁会优先给写锁队列中等候的获取锁请求，然后再给读锁队列中等候的获取锁请求。

三、InnoDB行锁

InnoDB实现了两种类型的行锁：

• 共享锁（S）：允许一个事务去读一行，阻止其他事务获得相同数据集的排他写锁
• 排他锁(X）：允许获得排他锁的事务更新数据，阻止其他事务取得相同数据集的共享读锁和排他写锁

为了允许行锁和表锁共存，实现多粒度锁的机制，InnoDB还有两种内部使用的意向锁，这两种意向锁都是表锁：

• 意向共享锁（IS）：事务打算给数据行加行共享锁，在加锁之前必须先取得该表的IS锁
• 意向排他锁（IX）：事务打算给数据行加行排他锁，在加锁之前必须先取得该表的IX锁

加锁机制
乐观锁会“乐观地”假定大概率不会发生并发更新冲突，访问、处理数据过程中不加锁，只在更新数据时再根据版本号或时间戳判断是否有冲突，有则处理，无则提交事务。用数据版本（Version）记录机制实现，这是乐观锁最常用的一种实现方式

悲观锁会“悲观地”假定大概率会发生并发更新冲突，访问、处理数据前就加排他锁，在整个数据处理过程中锁定数据，事务提交或回滚后才释放锁。另外与乐观锁相对应的，悲观锁是由数据库自己实现了的，要用的时候，我们直接调用数据库的相关语句就可以了。

锁模式

• 记录锁：单个行记录上的锁。对索引项加锁，锁定符合条件的行。其他事务不能修改和删除加锁项
• 间隙锁：当我们使用范围条件而不是相等条件检索数据，并请求共享或排他锁时，InnoDB会给符合条件的已有数据记录的索引项加锁。对于键值在条件范围内但并不存在的记录，叫做“间隙”，对间隙加锁，称为间隙锁。使用间隙锁锁住的是一个区间，而是这个区间上的每一条数据
• 临建锁：记录锁与间隙锁的组合，它的封锁范围，即包括索引记录，又包括索引区间。临建锁的主要目的，就是为了避免幻读

四、死锁

4.1死锁产生：

• 死锁是指两个或多个事务在同一资源上相互占用，并请求锁定对方占用的资源，从而导致恶性循环
• 当事务试图以不同的顺序锁定资源时，就可能产生死锁。多个事务同时锁定同一个资源时也可能会产生死锁
• 锁的行为和顺序和存储引擎相关。以同样的顺序执行语句，有些存储引擎会产生死锁有些不会——死锁有双重原因：真正的数据冲突；存储引擎的实现方式。

4.2 检测死锁：

数据库系统实现了各种死锁检测和死锁超时的机制。InnoDB存储引擎能检测到死锁的循环依赖并立即返回一个错误。

4.3 死锁恢复：

死锁发生以后，只有部分或完全回滚其中一个事务，才能打破死锁，InnoDB目前处理死锁的方法是，将持有最少行级排他锁的事务进行回滚。所以事务型应用程序在设计时必须考虑如何处理死锁，多数情况下只需要重新执行因死锁回滚的事务即可。

4.4 外部锁的死锁检测：

发生死锁后，InnoDB 一般都能自动检测到，并使一个事务释放锁并回退，另一个事务获得锁，继续完成事务。但在涉及外部锁，或涉及表锁的情况下，InnoDB 并不能完全自动检测到死锁， 这需要通过设置锁等待超时参数 innodb_lock_wait_timeout 来解决

4.5死锁影响性能：

死锁会影响性能而不是会产生严重错误，因为InnoDB会自动检测死锁状况并回滚其中一个受影响的事务。在高并发系统上，当许多线程等待同一个锁时，死锁检测可能导致速度变慢。有时当发生死锁时，禁用死锁检测（使用innodb_deadlock_detect配置选项）可能会更有效，这时可以依赖innodb_lock_wait_timeout设置进行事务回滚。

4.6MyISAM避免死锁：

在自动加锁的情况下，MyISAM 总是一次获得 SQL 语句所需要的全部锁，所以 MyISAM 表不会出现死锁。

4.7 InnoDB避免死锁：

• 为了在单个InnoDB表上执行多个并发写入操作时避免死锁，可以在事务开始时通过为预期要修改的每个元祖（行）使用SELECT … FOR UPDATE语句来获取必要的锁，即使这些行的更改语句是在之后才执行的。
• 在事务中，如果要更新记录，应该直接申请足够级别的锁，即排他锁，而不应先申请共享锁、更新时再申请排他锁，因为这时候当用户再申请排他锁时，其他事务可能又已经获得了相同记录的共享锁，从而造成锁冲突，甚至死锁
• 如果事务需要修改或锁定多个表，则应在每个事务中以相同的顺序使用加锁语句。在应用中，如果不同的程序会并发存取多个表，应尽量约定以相同的顺序来访问表，这样可以大大降低产生死锁的机会
• 通过SELECT … LOCK IN SHARE MODE获取行的读锁后，如果当前事务再需要对该记录进行更新操作，则很有可能造成死锁。
• 改变事务隔离级别

如果出现死锁，可以用 show engine innodb status;命令来确定最后一个死锁产生的原因。返回结果中包括死锁相关事务的详细信息，如引发死锁的 SQL 语句，事务已经获得的锁，正在等待什么锁，以及被回滚的事务等。据此可以分析死锁产生的原因和改进措施。