全面掌控MySQL加锁规则

时间  2020-10-02 标签 全面 掌控 mysql 加锁 规则

一、背景

　　MySQL/InnoDB的加锁分析，一直是一个比较困难的话题。我在工做过程当中，常常会有同事咨询这方面的问题。同时，微博上也常常会收到MySQL锁相关的私信，让我帮助解决一些死锁的问题。本文，准备就MySQL/InnoDB的加锁问题，展开较为深刻的分析与讨论，主要是介绍一种思路，运用此思路，拿到任何一条SQL语句，都能完整的分析出这条语句会加什么锁？会有什么样的使用风险？甚至是分析线上的一个死锁场景，了解死锁产生的缘由。html

注：MySQL是一个支持插件式存储引擎的数据库系统。本文下面的全部介绍，都是基于InnoDB存储引擎，其余引擎的表现，会有较大的区别。mysql

二、多版本并发控制MVCC：Snapshot Read vs Current Read

　　MySQL InnoDB存储引擎，实现的是基于多版本的并发控制协议——MVCC (Multi-Version Concurrency Control) (注：与MVCC相对的，是基于锁的并发控制，Lock-Based Concurrency Control)。MVCC最大的好处，相信也是耳熟能详：读不加锁，读写不冲突。在读多写少的OLTP应用中，读写不冲突是很是重要的，极大的增长了系统的并发性能，这也是为何现阶段，几乎全部的RDBMS，都支持了MVCC。sql

　　在MVCC并发控制中，读操做能够分红两类：快照读 (snapshot read)与当前读 (current read)。快照读，读取的是记录的可见版本 (有多是历史版本)，不用加锁。当前读，读取的是记录的最新版本，而且，当前读返回的记录，都会加上锁，保证其余事务不会再并发修改这条记录。数据库

　　在一个支持MVCC并发控制的系统中，哪些读操做是快照读？哪些操做又是当前读呢？以MySQL InnoDB为例：并发

 　　快照读：简单的select操做，属于快照读，不加锁。(固然，也有例外，下面会分析)性能

　　　　　　  select * from table where ?;优化

　　 当前读：特殊的读操做，插入/更新/删除操做，属于当前读，须要加锁。　　spa

　　　　　　　select * from table where ? lock in share mode;插件

                    select * from table where ? for update;htm

                    insert into table values (…);

                    update table set ? where ?;

                    delete from table where ?;

　　　　　　  全部以上的语句，都属于当前读，读取记录的最新版本。而且，读取以后，还须要保证其余并发事务不能修改当前记录，对读取记录加锁。其中，除了第一条语句，对读取记录加S锁 (共享锁)外，其余的操做，都加的是X锁 (排它锁)。

 

　　为何将 插入/更新/删除 操做，都归为当前读？能够看看下面这个 更新 操做，在数据库中的执行流程：

                           

　　从图中，能够看到，一个Update操做的具体流程。当Update SQL被发给MySQL后，MySQL Server会根据where条件，读取第一条知足条件的记录，而后InnoDB引擎会将第一条记录返回，并加锁 (current read)。待MySQL Server收到这条加锁的记录以后，会再发起一个Update请求，更新这条记录。一条记录操做完成，再读取下一条记录，直至没有知足条件的记录为止。所以，Update操做内部，就包含了一个当前读。同理，Delete操做也同样。Insert操做会稍微有些不一样，简单来讲，就是Insert操做可能会触发Unique Key的冲突检查，也会进行一个当前读。

注：根据上图的交互，针对一条当前读的SQL语句，InnoDB与MySQL Server的交互，是一条一条进行的，所以，加锁也是一条一条进行的。先对一条知足条件的记录加锁，返回给MySQL Server，作一些DML操做；而后在读取下一条加锁，直至读取完毕。

 

三、Cluster Index：聚簇索引

　　InnoDB存储引擎的数据组织方式，是聚簇索引表：完整的记录，存储在主键索引中，经过主键索引，就能够获取记录全部的列。关于聚簇索引表的组织方式，能够参考MySQL的官方文档：Clustered and Secondary Indexes 。本文假设读者对这个，已经有了必定的认识，就再也不作具体的介绍。接下来的部分，主键索引/聚簇索引 两个名称，会有一些混用，望读者知晓。

 

四、2PL：Two-Phase Locking

　　传统RDBMS加锁的一个原则，就是2PL (二阶段锁)：Two-Phase Locking。相对而言，2PL比较容易理解，说的是锁操做分为两个阶段：加锁阶段与解锁阶段，而且保证加锁阶段与解锁阶段不相交。下面，仍旧以MySQL为例，来简单看看2PL在MySQL中的实现。

　　　　　　  

　　　　从上图能够看出，2PL就是将加锁/解锁分为两个彻底不相交的阶段。加锁阶段：只加锁，不放锁。解锁阶段：只放锁，不加锁。

五、事务隔离级别Isolation Level

　　隔离级别：Isolation Level，也是RDBMS的一个关键特性。相信对数据库有所了解的朋友，对于4种隔离级别：Read Uncommited，Read Committed，Repeatable Read，Serializable，都有了深刻的认识。本文不打算讨论数据库理论中，是如何定义这4种隔离级别的含义的，而是跟你们介绍一下MySQL/InnoDB是如何定义这4种隔离级别的。

　　MySQL/InnoDB定义的4种隔离级别：

    • Read Uncommited

      能够读取未提交记录。此隔离级别，不会使用，忽略。

    • Read Committed (RC)

      快照读忽略，本文不考虑。

      针对当前读，RC隔离级别保证对读取到的记录加锁 (记录锁)，存在幻读现象。

    • Repeatable Read (RR)

      快照读忽略，本文不考虑。

      针对当前读，RR隔离级别保证对读取到的记录加锁 (记录锁)，同时保证对读取的范围加锁，新的知足查询条件的记录不可以插入 (间隙锁)，不存在幻读现象。

    • Serializable

      从MVCC并发控制退化为基于锁的并发控制。不区别快照读与当前读，全部的读操做均为当前读，读加读锁 (S锁)，写加写锁 (X锁)。

      Serializable隔离级别下，读写冲突，所以并发度急剧降低，在MySQL/InnoDB下不建议使用。

 

六、加锁过程分析

1）一条简单SQL的加锁实现分析

　　在介绍完一些背景知识以后，本文接下来将选择几个有表明性的例子，来详细分析MySQL的加锁处理。固然，仍是从最简单的例子提及。常常有朋友发给我一个SQL，而后问我，这个SQL加什么锁？就如同下面两条简单的SQL，他们加什么锁？

  • SQL1：select * from t1 where id = 10;
  • SQL2：delete from t1 where id = 10;

 

　　针对这个问题，该怎么回答？我能想象到的一个答案是：

  • SQL1：不加锁。由于MySQL是使用多版本并发控制的，读不加锁。
  • SQL2：对id = 10的记录加写锁 (走主键索引)。

 

　　这个答案对吗？说不上来。便可能是正确的，也有多是错误的，已知条件不足，这个问题没有答案。若是让我来回答这个问题，我必须还要知道如下的一些前提，前提不一样，我能给出的答案也就不一样。要回答这个问题，还缺乏哪些前提条件？

 

  • 前提一：id列是否是主键？

 

  • 前提二：当前系统的隔离级别是什么？
  • 前提三：id列若是不是主键，那么id列上有索引吗？
  • 前提四：id列上若是有二级索引，那么这个索引是惟一索引吗？
  • 前提五：两个SQL的执行计划是什么？索引扫描？全表扫描？

 

没有这些前提，直接就给定一条SQL，而后问这个SQL会加什么锁，都是很业余的表现。而当这些问题有了明确的答案以后，给定的SQL会加什么锁，也就一目了然。下面，我将这些问题的答案进行组合，而后按照从易到难的顺序，逐个分析每种组合下，对应的SQL会加哪些锁？

 

注：下面的这些组合，我作了一个前提假设，也就是有索引时，执行计划必定会选择使用索引进行过滤 (索引扫描)。但实际状况会复杂不少，真正的执行计划，仍是须要根据MySQL输出的为准。

 

  • 组合一：id列是主键，RC隔离级别
  • 组合二：id列是二级惟一索引，RC隔离级别
  • 组合三：id列是二级非惟一索引，RC隔离级别
  • 组合四：id列上没有索引，RC隔离级别
  • 组合五：id列是主键，RR隔离级别
  • 组合六：id列是二级惟一索引，RR隔离级别
  • 组合七：id列是二级非惟一索引，RR隔离级别
  • 组合八：id列上没有索引，RR隔离级别
  • 组合九：Serializable隔离级别

 

排列组合尚未列举彻底，可是看起来，已经不少了。真的有必要这么复杂吗？事实上，要分析加锁，就是须要这么复杂。可是从另外一个角度来讲，只要你选定了一种组合，SQL须要加哪些锁，其实也就肯定了。接下来，就让咱们来逐个分析这9种组合下的SQL加锁策略。

 

注：在前面八种组合下，也就是RC，RR隔离级别下，SQL1：select操做均不加锁，采用的是快照读，所以在下面的讨论中就忽略了，主要讨论SQL2：delete操做的加锁。

 

组合一：id主键+RC

　　这个组合，是最简单，最容易分析的组合。id是主键，Read Committed隔离级别，给定SQL：delete from t1 where id = 10; 只须要将主键上，id = 10的记录加上X锁便可。以下图所示：

　　　　　　　　　　　　　　　　　　　　　　　　

　　　　　　结论：id是主键时，此SQL只须要在id=10这条记录上加X锁便可。

     

 组合二：id惟一索引+RC 

　　这个组合，id不是主键，而是一个Unique的二级索引键值。那么在RC隔离级别下，delete from t1 where id = 10; 须要加什么锁呢？见下图：

　　　　　                     　

　　此组合中，id是unique索引，而主键是name列。此时，加锁的状况因为组合一有所不一样。因为id是unique索引，所以delete语句会选择走id列的索引进行where条件的过滤，在找到id=10的记录后，首先会将unique索引上的id=10索引记录加上X锁，同时，会根据读取到的name列，回主键索引(聚簇索引)，而后将聚簇索引上的name = ‘d’ 对应的主键索引项加X锁。为何聚簇索引上的记录也要加锁？试想一下，若是并发的一个SQL，是经过主键索引来更新：update t1 set id = 100 where name = ‘d’; 此时，若是delete语句没有将主键索引上的记录加锁，那么并发的update就会感知不到delete语句的存在，违背了同一记录上的更新/删除须要串行执行的约束。

 

结论：若id列是unique列，其上有unique索引。那么SQL须要加两个X锁，一个对应于id unique索引上的id = 10的记录，另外一把锁对应于聚簇索引上的[name='d',id=10]的记录。

 

组合三：id非惟一索引+RC

　　相对于组合1、二，组合三又发生了变化，隔离级别仍旧是RC不变，可是id列上的约束又下降了，id列再也不惟一，只有一个普通的索引。假设delete from t1 where id = 10; 语句，仍旧选择id列上的索引进行过滤where条件，那么此时会持有哪些锁？一样见下图：

               　　　　  

　　根据此图，能够看到，首先，id列索引上，知足id = 10查询条件的记录，均已加锁。同时，这些记录对应的主键索引上的记录也都加上了锁。与组合二惟一的区别在于，组合二最多只有一个知足等值查询的记录，而组合三会将全部知足查询条件的记录都加锁。

 

结论：若id列上有非惟一索引，那么对应的全部知足SQL查询条件的记录，都会被加锁。同时，这些记录在主键索引上的记录，也会被加锁。

 

 

组合四：id无索引+RC

　　相对于前面三个组合，这是一个比较特殊的状况。id列上没有索引，where id = 10;这个过滤条件，无法经过索引进行过滤，那么只能走全表扫描作过滤。对应于这个组合，SQL会加什么锁？或者是换句话说，全表扫描时，会加什么锁？这个答案也有不少：有人说会在表上加X锁；有人说会将聚簇索引上，选择出来的id = 10;的记录加上X锁。那么实际状况呢？请看下图：

                  

　　因为id列上没有索引，所以只能走聚簇索引，进行所有扫描。从图中能够看到，知足删除条件的记录有两条，可是，聚簇索引上全部的记录，都被加上了X锁。不管记录是否知足条件，所有被加上X锁。既不是加表锁，也不是在知足条件的记录上加行锁。

 

　　有人可能会问？为何不是只在知足条件的记录上加锁呢？这是因为MySQL的实现决定的。若是一个条件没法经过索引快速过滤，那么存储引擎层面就会将全部记录加锁后返回，而后由MySQL Server层进行过滤。所以也就把全部的记录，都锁上了。

 

注：在实际的实现中，MySQL有一些改进，在MySQL Server过滤条件，发现不知足后，会调用unlock_row方法，把不知足条件的记录放锁 (违背了2PL的约束)。这样作，保证了最后只会持有知足条件记录上的锁，可是每条记录的加锁操做仍是不能省略的。

 

结论：若id列上没有索引，SQL会走聚簇索引的全扫描进行过滤，因为过滤是由MySQL Server层面进行的。所以每条记录，不管是否知足条件，都会被加上X锁。可是，为了效率考量，MySQL作了优化，对于不知足条件的记录，会在判断后放锁，最终持有的，是知足条件的记录上的锁，可是不知足条件的记录上的加锁/放锁动做不会省略。同时，优化也违背了2PL的约束。

 

组合五：id主键+RR

　　上面的四个组合，都是在Read Committed隔离级别下的加锁行为，接下来的四个组合，是在Repeatable Read隔离级别下的加锁行为。

 

　　组合五，id列是主键列，Repeatable Read隔离级别，针对delete from t1 where id = 10; 这条SQL，加锁与组合一：[id主键，Read Committed]一致。

 

组合六：id惟一索引+RR

　　与组合五相似，组合六的加锁，与组合二：[id惟一索引，Read Committed]一致。两个X锁，id惟一索引知足条件的记录上一个，对应的聚簇索引上的记录一个。

 

组合七：id非惟一索引+RR

　　还记得前面提到的MySQL的四种隔离级别的区别吗？RC隔离级别容许幻读，而RR隔离级别，不容许存在幻读。可是在组合5、组合六中，加锁行为又是与RC下的加锁行为彻底一致。那么RR隔离级别下，如何防止幻读呢？问题的答案，就在组合七中揭晓。

 

　　组合七，Repeatable Read隔离级别，id上有一个非惟一索引，执行delete from t1 where id = 10; 假设选择id列上的索引进行条件过滤，最后的加锁行为，是怎么样的呢？一样看下面这幅图：

　　　　　　

　　此图，相对于组合三：[id列上非惟一锁，Read Committed]看似相同，其实却有很大的区别。最大的区别在于，这幅图中多了一个GAP锁，并且GAP锁看起来也不是加在记录上的，倒像是加载两条记录之间的位置，GAP锁有何用？

 

　　其实这个多出来的GAP锁，就是RR隔离级别，相对于RC隔离级别，不会出现幻读的关键。确实，GAP锁锁住的位置，也不是记录自己，而是两条记录之间的GAP。所谓幻读，就是同一个事务，连续作两次当前读 (例如：select * from t1 where id = 10 for update;)，那么这两次当前读返回的是彻底相同的记录 (记录数量一致，记录自己也一致)，第二次的当前读，不会比第一次返回更多的记录 (幻象)。

 

　　如何保证两次当前读返回一致的记录，那就须要在第一次当前读与第二次当前读之间，其余的事务不会插入新的知足条件的记录并提交。为了实现这个功能，GAP锁应运而生。

 

　　如图中所示，有哪些位置能够插入新的知足条件的项 (id = 10)，考虑到B+树索引的有序性，知足条件的项必定是连续存放的。记录[6,c]以前，不会插入id=10的记录；[6,c]与[10,b]间能够插入[10, aa]；[10,b]与[10,d]间，能够插入新的[10,bb],[10,c]等；[10,d]与[11,f]间能够插入知足条件的[10,e],[10,z]等；而[11,f]以后也不会插入知足条件的记录。所以，为了保证[6,c]与[10,b]间，[10,b]与[10,d]间，[10,d]与[11,f]不会插入新的知足条件的记录，MySQL选择了用GAP锁，将这三个GAP给锁起来。

 

　　Insert操做，如insert [10,aa]，首先会定位到[6,c]与[10,b]间，而后在插入前，会检查这个GAP是否已经被锁上，若是被锁上，则Insert不能插入记录。所以，经过第一遍的当前读，不只将知足条件的记录锁上 (X锁)，与组合三相似。同时仍是增长3把GAP锁，将可能插入知足条件记录的3个GAP给锁上，保证后续的Insert不能插入新的id=10的记录，也就杜绝了同一事务的第二次当前读，出现幻象的状况。

 

　　有心的朋友看到这儿，能够会问：既然防止幻读，须要靠GAP锁的保护，为何组合5、组合六，也是RR隔离级别，却不须要加GAP锁呢？

 

　　首先，这是一个好问题。其次，回答这个问题，也很简单。GAP锁的目的，是为了防止同一事务的两次当前读，出现幻读的状况。而组合五，id是主键；组合六，id是unique键，都可以保证惟一性。一个等值查询，最多只能返回一条记录，并且新的相同取值的记录，必定不会在新插入进来，所以也就避免了GAP锁的使用。其实，针对此问题，还有一个更深刻的问题：若是组合5、组合六下，针对SQL：select * from t1 where id = 10 for update; 第一次查询，没有找到知足查询条件的记录，那么GAP锁是否还可以省略？此问题留给你们思考。

 

结论：Repeatable Read隔离级别下，id列上有一个非惟一索引，对应SQL：delete from t1 where id = 10; 首先，经过id索引定位到第一条知足查询条件的记录，加记录上的X锁，加GAP上的GAP锁，而后加主键聚簇索引上的记录X锁，而后返回；而后读取下一条，重复进行。直至进行到第一条不知足条件的记录[11,f]，此时，不须要加记录X锁，可是仍旧须要加GAP锁，最后返回结束。

 

 

组合八：id无索引+RR

　　组合八，Repeatable Read隔离级别下的最后一种状况，id列上没有索引。此时SQL：delete from t1 where id = 10; 没有其余的路径能够选择，只能进行全表扫描。最终的加锁状况，以下图所示：

   　　　　       

　　如图，这是一个很恐怖的现象。首先，聚簇索引上的全部记录，都被加上了X锁。其次，聚簇索引每条记录间的间隙(GAP)，也同时被加上了GAP锁。这个示例表，只有6条记录，一共须要6个记录锁，7个GAP锁。试想，若是表上有1000万条记录呢？

 

　　在这种状况下，这个表上，除了不加锁的快照度，其余任何加锁的并发SQL，均不能执行，不能更新，不能删除，不能插入，全表被锁死。

 

　　固然，跟组合四：[id无索引, Read Committed]相似，这个状况下，MySQL也作了一些优化，就是所谓的semi-consistent read。semi-consistent read开启的状况下，对于不知足查询条件的记录，MySQL会提早放锁。针对上面的这个用例，就是除了记录[d,10]，[g,10]以外，全部的记录锁都会被释放，同时不加GAP锁。semi-consistent read如何触发：要么是read committed隔离级别；要么是Repeatable Read隔离级别，同时设置了innodb_locks_unsafe_for_binlog 参数。更详细的关于semi-consistent read的介绍，可参考我以前的一篇博客：MySQL+InnoDB semi-consitent read原理及实现分析 。

 

结论：在Repeatable Read隔离级别下，若是进行全表扫描的当前读，那么会锁上表中的全部记录，同时会锁上聚簇索引内的全部GAP，杜绝全部的并发 更新/删除/插入 操做。固然，也能够经过触发semi-consistent read，来缓解加锁开销与并发影响，可是semi-consistent read自己也会带来其余问题，不建议使用。

 

组合九：Serializable

　　针对前面提到的简单的SQL，最后一个状况：Serializable隔离级别。对于SQL2：delete from t1 where id = 10; 来讲，Serializable隔离级别与Repeatable Read隔离级别彻底一致，所以不作介绍。

 

　　Serializable隔离级别，影响的是SQL1：select * from t1 where id = 10; 这条SQL，在RC，RR隔离级别下，都是快照读，不加锁。可是在Serializable隔离级别，SQL1会加读锁，也就是说快照读不复存在，MVCC并发控制降级为Lock-Based CC。

 

结论：在MySQL/InnoDB中，所谓的读不加锁，并不适用于全部的状况，而是隔离级别相关的。Serializable隔离级别，读不加锁就再也不成立，全部的读操做，都是当前读。

 

2）一条复杂的sql语句

　　写到这里，其实MySQL的加锁实现也已经介绍的八八九九。只要将本文上面的分析思路，大部分的SQL，都能分析出其会加哪些锁。而这里，再来看一个稍微复杂点的SQL，用于说明MySQL加锁的另一个逻辑。SQL用例以下：

　　　　　　

　　　　如图中的SQL，会加什么锁？假定在Repeatable Read隔离级别下 (Read Committed隔离级别下的加锁状况，留给读者分析。)，同时，假设SQL走的是idx_t1_pu索引。

 

　　　　在详细分析这条SQL的加锁状况前，还须要有一个知识储备，那就是一个SQL中的where条件如何拆分？具体的介绍，建议阅读我以前的一篇文章：SQL中的where条件，在数据库中提取与应用浅析 。在这里，我直接给出分析后的结果：

 

    • 　　Index key：pubtime > 1 and puptime < 20。此条件，用于肯定SQL在idx_t1_pu索引上的查询范围。

       

    • 　　Index Filter：userid = ‘hdc’ 。此条件，能够在idx_t1_pu索引上进行过滤，但不属于Index Key。
    • 　　Table Filter：comment is not NULL。此条件，在idx_t1_pu索引上没法过滤，只能在聚簇索引上过滤。

 

　　在分析出SQL where条件的构成以后，再来看看这条SQL的加锁状况 (RR隔离级别)，以下图所示：

 　　　　

　　从图中能够看出，在Repeatable Read隔离级别下，由Index Key所肯定的范围，被加上了GAP锁；Index Filter锁给定的条件 (userid = ‘hdc’)什么时候过滤，视MySQL的版本而定，在MySQL 5.6版本以前，不支持Index Condition Pushdown(ICP)，所以Index Filter在MySQL Server层过滤，在5.6后支持了Index Condition Pushdown，则在index上过滤。若不支持ICP，不知足Index Filter的记录，也须要加上记录X锁，若支持ICP，则不知足Index Filter的记录，无需加记录X锁 (图中，用红色箭头标出的X锁，是否要加，视是否支持ICP而定)；而Table Filter对应的过滤条件，则在聚簇索引中读取后，在MySQL Server层面过滤，所以聚簇索引上也须要X锁。最后，选取出了一条知足条件的记录[8,hdc,d,5,good]，可是加锁的数量，要远远大于知足条件的记录数量。

 

结论：在Repeatable Read隔离级别下，针对一个复杂的SQL，首先须要提取其where条件。Index Key肯定的范围，须要加上GAP锁；Index Filter过滤条件，视MySQL版本是否支持ICP，若支持ICP，则不知足Index Filter的记录，不加X锁，不然须要X锁；Table Filter过滤条件，不管是否知足，都须要加X锁。

 

七、死锁原理与分析

　　本文前面的部分，基本上已经涵盖了MySQL/InnoDB全部的加锁规则。深刻理解MySQL如何加锁，有两个比较重要的做用：

 

  • 能够根据MySQL的加锁规则，写出不会发生死锁的SQL；

     

  • 能够根据MySQL的加锁规则，定位出线上产生死锁的缘由；

　　下面，来看看两个死锁的例子 (一个是两个Session的两条SQL产生死锁；另外一个是两个Session的一条SQL，产生死锁)：

　　　　

 

　　　　

　　上面的两个死锁用例。第一个很是好理解，也是最多见的死锁，每一个事务执行两条SQL，分别持有了一把锁，而后加另外一把锁，产生死锁。

 

　　第二个用例，虽然每一个Session都只有一条语句，仍旧会产生死锁。要分析这个死锁，首先必须用到本文前面提到的MySQL加锁的规则。针对Session 1，从name索引出发，读到的[hdc, 1]，[hdc, 6]均知足条件，不只会加name索引上的记录X锁，并且会加聚簇索引上的记录X锁，加锁顺序为先[1,hdc,100]，后[6,hdc,10]。而Session 2，从pubtime索引出发，[10,6],[100,1]均知足过滤条件，一样也会加聚簇索引上的记录X锁，加锁顺序为[6,hdc,10]，后[1,hdc,100]。发现没有，跟Session 1的加锁顺序正好相反，若是两个Session刚好都持有了第一把锁，请求加第二把锁，死锁就发生了。　　

 

结论：死锁的发生与否，并不在于事务中有多少条SQL语句，死锁的关键在于：两个(或以上)的Session加锁的顺序不一致。而使用本文上面提到的，分析MySQL每条SQL语句的加锁规则，分析出每条语句的加锁顺序，而后检查多个并发SQL间是否存在以相反的顺序加锁的状况，就能够分析出各类潜在的死锁状况，也能够分析出线上死锁发生的缘由。

 

八、总结

　　写到这儿，本文也告一段落，作一个简单的总结，要作的彻底掌握MySQL/InnoDB的加锁规则，甚至是其余任何数据库的加锁规则，须要具有如下的一些知识点：

 

  • 了解数据库的一些基本理论知识：数据的存储格式 (堆组织表 vs 聚簇索引表)；并发控制协议 (MVCC vs Lock-Based CC)；Two-Phase Locking；数据库的隔离级别定义 (Isolation Level)；
  • 了解SQL自己的执行计划 (主键扫描 vs 惟一键扫描 vs 范围扫描 vs 全表扫描)；
  • 了解数据库自己的一些实现细节 (过滤条件提取；Index Condition Pushdown；Semi-Consistent Read)；
  • 了解死锁产生的缘由及分析的方法 (加锁顺序不一致；分析每一个SQL的加锁顺序)

 

　　有了这些知识点，再加上适当的实战经验，全面掌控MySQL/InnoDB的加锁规则，当不在话下。

联系我们 沪ICP备13005482号-10