一、背景知识
Mysql innodb如何进行数据读取，什么样的数据读取需要加锁，数据隔离级别是什么样的，什么情况下该使用什么类型的锁，锁定的方式又是什么，在本小节梳理了相关背景知识，解答了以上疑问，以更清晰地了解锁机制及死锁产生的原因。
1.1.MVCC：快照读（Snapshot Read）与当前读（Current Read）
MySQL InnoDB存储引擎，实现的是基于多版本的并发控制协议——MVCC (Multi-Version Concurrency Control) (注：与MVCC相对的，是基于锁的并发控制，Lock-Based Concurrency Control)。其最大的优点是：读不加锁，读写不冲突。在读多写少的OLTP应用中，读写不冲突是非常重要的，极大的增加了系统的并发性能，这也是为什么现阶段，几乎所有的RDBMS，都支持了MVCC。
MVCC读取数据的方式分为快照读和当前读两种方式。快照读：读取指定版本，不需要加锁，如简单的select操作；当前读：读取的是记录的最新版本，并且，当前读返回的记录，都会加上锁，保证其他事务不会再并发修改这条记录。如插入、更新、删除操作，均需要进行加锁。之所以将这些操作归为当前读，用更新操作举例，在进行更新操作前，首先会读取当前的待更新数据库字段的值进行返回并加锁（当前读），待mysql收到这个加锁记录后，才会发起一个update的操作，更新该记录。删除操作同理，插入操作稍有不同，简单地说在执行插入前可能会触发唯一键检查操作，也会进行一个当前读。
1.2.事务的四种隔离级别
在数据库操作中，为了有效保证并发读取数据的正确性，提出的事务隔离级别。数据库锁也是为了构建这些隔离级别存在的。
| 隔离级别 | 脏读（Dirty Read） | 不可重复读（NonRepeatable Read） | 幻读（Phantom Read） |
|---|---|---|---|
| 未提交读（Read uncommitted） | 可能 | 可能 | 可能 |
| 已提交读（Read committed） | 不可能 | 可能 | 可能 |
| 可重复读（Repeatable read） | 不可能 | 不可能 | 可能 |
| 可串行化（Serializable ） | 不可能 | 不可能 | 不可能 |
- 未提交读(Read Uncommitted)：允许脏读，也就是可能读取到其他会话中未提交事务修改的数据
- 提交读(Read Committed)：只能读取到已经提交的数据。Oracle等多数数据库默认都是该级别 (不重复读)
- 可重复读(Repeated Read)：可重复读。在同一个事务内的查询都是事务开始时刻一致的，InnoDB默认级别。在SQL标准中，该隔离级别消除了不可重复读，但是还存在幻象读
- 串行读(Serializable)：完全串行化的读，每次读都需要获得表级共享锁，读写相互都会阻塞
1.3.数据库锁类型
根据对资源操作的不同，对资源锁定的级别也有所不同。MySQL InnoDB存储引擎的锁类型分为以下几种。
| 锁类型 | 描述 |
|---|---|
| 共享锁(S) | 允许一个事务去读一行，阻止其他事务获得相同数据集的排他锁。 |
| 排他锁(X) | 允许获得排他锁的事务更新数据，阻止其他事务取得相同数据集的共享读锁和排他写锁。 |
| 意向共享锁(IS) | 事务打算给数据行加行共享锁，事务在给一个数据行加共享锁前必须先取得该表的IS锁。 |
| 意向排他锁(IX) | 事务打算给数据行加行排他锁，事务在给一个数据行加排他锁前必须先取得该表的IX锁。 |
上述锁类型之间的兼容关系如下
| X | IX | S | IS | |
| X | 冲突 | 冲突 | 冲突 | 冲突 |
| IX | 冲突 | 兼容 | 冲突 | 兼容 |
| S | 冲突 | 冲突 | 兼容 | 兼容 |
| IS | 冲突 | 兼容 | 兼容 | 兼容 |
如果一个事务请求的锁模式与当前的锁兼容，InnoDB就将请求的锁授予该事务；反之，如果两者不兼容，该事务就要等待锁释放。
意向锁是InnoDB自动加的，不需用户干预。对于当前读操作，InnoDB会自动给涉及数据集加排他锁（X)；对于快照读操作，InnoDB不会加任何锁；事务可以通过以下语句显示给记录集加共享锁或排他锁。
共享锁（S）：SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE。
排他锁（X)：SELECT * FROM table_name WHERE ... FOR UPDATE。
用SELECT ... IN SHARE MODE获得共享锁，主要用在需要数据依存关系时来确认某行记录是否存在，并确保没有人对这个记录进行UPDATE或者DELETE操作。但是如果当前事务也需要对该记录进行更新操作，则很有可能造成死锁，对于锁定行记录后需要进行更新操作的应用，应该使用SELECT... FOR UPDATE方式获得排他锁。
1.4.锁定方式
mysql innodb支持三种行锁定方式：
行锁（Record Lock）:锁直接加在索引记录上面，锁住的是key。
间隙锁（Gap Lock）:锁定索引记录间隙，确保索引记录的间隙不变。间隙锁是针对事务隔离级别为可重复读或以上级别。
Next-Key Lock ：行锁和间隙锁组合起来就叫Next-Key Lock。
默认情况下，InnoDB工作在可重复读隔离级别下，并且会以Next-Key Lock的方式对数据行进行加锁，这样可以有效防止幻读的发生。Next-Key Lock是行锁和间隙锁的组合，当InnoDB扫描索引记录的时候，会首先对索引记录加上行锁（Record Lock），再对索引记录两边的间隙加上间隙锁（Gap Lock）。加上间隙锁之后，其他事务就不能在这个间隙修改或者插入记录。
二、数据库死锁定义及其产生的必要条件
所谓数据库死锁是指两个或多个事务，各自占有对方的期望获得的资源，形成的循环等待，彼此无法继续正常执行的一种状态。
从业务层看死锁产生具有一定的概率性，当具备了以下几个必要条件时，则会出现死锁：
- 互斥条件：指进程对所分配到的资源进行排它性使用，即在一段时间内某资源只由一个进程占用。如果此时还有其它进程请求资源，则请求者只能等待，直至占有资源的进程用完释放。
- 请求和保持条件：指进程已经保持至少一个资源，但又提出了新的资源请求，而该资源已被其它进程占有，此时请求进程阻塞，但又对自己获得的其它资源保持不放。
- 不剥夺条件：指进程已获得的资源，在未使用完之前，不能被剥夺，只能在使用完时由自己释放。
- 环路等待条件：指在发生死锁时，必然存在一个进程——资源的环形链，即进程集合{P0，P1，P2，···，Pn}中的P0正在等待一个P1占用的资源；P1正在等待P2占用的资源，……，Pn正在等待已被P0占用的资源。
三、死锁问题示例及解决方法
示例1：
t_example1表 (F_column_1 primary key, F_id)
| F_id | F_column_1 | …… |
|---|---|---|
| 1 | 1 | |
| 2 | 2 | |
| 3 | 3 |
t_example2表（F_column_2 primary key, F_id）
| F_id | F_column_2 | …… |
|---|---|---|
| 1 | 1 | |
| 2 | 2 | |
| 3 | 3 |
| session 1 | session 2 |
|---|---|
| begin transaction | begin transaction |
| select * from t_example1 where F_column_1=1 for update | |
| select * from t_example2 where F_column_2=3 for update | |
| select * from t_example2 where F_column_2=3 for update | |
| select * from t_example1 where F_column_1=1 for update |
分析：上述死锁示例是比较常见的一种死锁，由于两个事务分别持有了一个行锁，分别等待对方释放所持有的行锁，因此导致了死锁。
示例2：
t_example3(F_id primary key, F_user_id ）建立的索引为key (F_user_id)
| F_id | F_user_id | …… |
|---|---|---|
| 1 | 1 | |
| 2 | 3 | |
| 3 | 5 |
| session 1 | session 2 |
|---|---|
| begin transaction | begin transaction |
| select XX from t_example3 where F_user_id=3 for update | |
| update t_example1 set XX where F_column_1=1 | |
| update t_example1 set XX where F_column_1=1 | |
| insert into t_example3 (F_id,F_user_id)values(4,2） |
分析：示例2之所以会产生死锁，因为表t_example3对F_user_id创建的是一个普通索引，session1在根据F_user_id查询条件执行select for update时，锁定的是上一条记录到下一条记录之间的区间，因此，该锁锁定区间为从记录1到5之间的区间，session2事务首先持有了表example1的F_column_1的行锁，接下来想要向表三种插入F_user_id=2的记录，其需要锁定的是记录1到记录3之间的区间，而其所尝试锁定的部分区间已经被session1的事务锁定，因此进入了等待状态，此时，session1的事务等待session2的事务所持有的表t_example1的F_column_1=1的行锁的释放，因此出现了死锁。
当出现死锁后，通常采用破坏死锁产生的四个必要条件其中的一个或多个，来解决死锁问题。
1）确保资源按照指定的顺序推进，破坏环状等待的现状
上述示例一解决方法：将其中一个事务的sql执行顺序调整，确保加锁的顺序一致，从而避免死锁。
2）尽可能缩小锁定资源的区间，避免gap锁所导致的死锁问题
上述示例二解决方法：将t_example3表的索引由普通索引改成唯一索引，缩小锁定区间，解决间隙锁导致的死锁问题。
3）设置锁超时时间，达到指定阈值后自动释放锁，破坏请求并保持条件
这种方式相对被动，通过判断锁持有时间，超过指定阈值后，则释放其所持有的锁定资源，交由业务自身重试处理，使等待该资源的其他事务得以推进。目前的分布式数据库死锁，则是采用的锁超时的处理方式来解决不同分片上出现的死锁问题。
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
