一站式网站设计,怎么可以建网站,做产品类的工作上什么网站好,seo 网站改版MySQL/InnoDB的加锁分析#xff0c;一直是一个比较困难的话题。我在工作过程中#xff0c;经常会有同事咨询这方面的问题。同时#xff0c;微博上也经常会收到MySQL锁相关的私信#xff0c;让我帮助解决一些死锁的问题。本文#xff0c;准备就MySQL/InnoDB的加锁问题… MySQL/InnoDB的加锁分析一直是一个比较困难的话题。我在工作过程中经常会有同事咨询这方面的问题。同时微博上也经常会收到MySQL锁相关的私信让我帮助解决一些死锁的问题。本文准备就MySQL/InnoDB的加锁问题展开较为深入的分析与讨论主要是介绍一种思路运用此思路拿到任何一条SQL语句都能完整的分析出这条语句会加什么锁会有什么样的使用风险甚至是分析线上的一个死锁场景了解死锁产生的原因。 注MySQL是一个支持插件式存储引擎的数据库系统。本文下面的所有介绍都是基于InnoDB存储引擎其他引擎的表现会有较大的区别。 MVCCSnapshot Read vs Current Read MySQL InnoDB存储引擎实现的是基于多版本的并发控制协议——MVCC (Multi-Version Concurrency Control) (注与MVCC相对的是基于锁的并发控制Lock-Based Concurrency Control)。MVCC最大的好处相信也是耳熟能详读不加锁读写不冲突。在读多写少的OLTP应用中读写不冲突是非常重要的极大的增加了系统的并发性能这也是为什么现阶段几乎所有的RDBMS都支持了MVCC。 在MVCC并发控制中读操作可以分成两类快照读 (snapshot read)与当前读 (current read)。快照读读取的是记录的可见版本 (有可能是历史版本)不用加锁。当前读读取的是记录的最新版本并且当前读返回的记录都会加上锁保证其他事务不会再并发修改这条记录。 在一个支持MVCC并发控制的系统中哪些读操作是快照读哪些操作又是当前读呢以MySQL InnoDB为例 快照读简单的select操作属于快照读不加锁。(当然也有例外下面会分析) select * from table where ?; 当前读特殊的读操作插入/更新/删除操作属于当前读需要加锁。 select * from table where ? lock in share mode; select * from table where ? for update; 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 。本文假设读者对这个已经有了一定的认识就不再做具体的介绍。接下来的部分主键索引/聚簇索引 两个名称会有一些混用望读者知晓。 2PLTwo-Phase Locking 传统RDBMS加锁的一个原则就是2PL (二阶段锁)Two-Phase Locking。相对而言2PL比较容易理解说的是锁操作分为两个阶段加锁阶段与解锁阶段并且保证加锁阶段与解锁阶段不相交。下面仍旧以MySQL为例来简单看看2PL在MySQL中的实现。 从上图可以看出2PL就是将加锁/解锁分为两个完全不相交的阶段。加锁阶段只加锁不放锁。解锁阶段只放锁不加锁。 Isolation Level 隔离级别Isolation Level也是RDBMS的一个关键特性。相信对数据库有所了解的朋友对于4种隔离级别Read UncommitedRead CommittedRepeatable ReadSerializable都有了深入的认识。本文不打算讨论数据库理论中是如何定义这4种隔离级别的含义的而是跟大家介绍一下MySQL/InnoDB是如何定义这4种隔离级别的。 MySQL/InnoDB定义的4种隔离级别 Read Uncommited 可以读取未提交记录。此隔离级别不会使用忽略。 Read Committed (RC) 快照读忽略本文不考虑。 针对当前读RC隔离级别保证对读取到的记录加锁 (记录锁)存在幻读现象。 Repeatable Read (RR) 快照读忽略本文不考虑。 针对当前读RR隔离级别保证对读取到的记录加锁 (记录锁)同时保证对读取的范围加锁新的满足查询条件的记录不能够插入 (间隙锁)不存在幻读现象。 Serializable 从MVCC并发控制退化为基于锁的并发控制。不区别快照读与当前读所有的读操作均为当前读读加读锁 (S锁)写加写锁 (X锁)。 Serializable隔离级别下读写冲突因此并发度急剧下降在MySQL/InnoDB下不建议使用。 一条简单SQL的加锁实现分析 在介绍完一些背景知识之后本文接下来将选择几个有代表性的例子来详细分析MySQL的加锁处理。当然还是从最简单的例子说起。经常有朋友发给我一个SQL然后问我这个SQL加什么锁就如同下面两条简单的SQL他们加什么锁 SQL1select * from t1 where id 10; SQL2delete 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加锁策略。 注在前面八种组合下也就是RCRR隔离级别下SQL1select操作均不加锁采用的是快照读因此在下面的讨论中就忽略了主要讨论SQL2delete操作的加锁。 组合一id主键RC 这个组合是最简单最容易分析的组合。id是主键Read Committed隔离级别给定SQLdelete from t1 where id 10; 只需要将主键上id 10的记录加上X锁即可。如下图所示 结论id是主键时此SQL只需要在id10这条记录上加X锁即可。 组合二id唯一索引RC 这个组合id不是主键而是一个Unique的二级索引键值。那么在RC隔离级别下delete from t1 where id 10; 需要加什么锁呢见下图 此组合中id是unique索引而主键是name列。此时加锁的情况由于组合一有所不同。由于id是unique索引因此delete语句会选择走id列的索引进行where条件的过滤在找到id10的记录后首先会将unique索引上的id10索引记录加上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的记录另一把锁对应于聚簇索引上的[named,id10]的记录。 组合三id非唯一索引RC 相对于组合一、二组合三又发生了变化隔离级别仍旧是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隔离级别不允许存在幻读。但是在组合五、组合六中加锁行为又是与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]之前不会插入id10的记录[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不能插入新的id10的记录也就杜绝了同一事务的第二次当前读出现幻象的情况。 有心的朋友看到这儿可以会问既然防止幻读需要靠GAP锁的保护为什么组合五、组合六也是RR隔离级别却不需要加GAP锁呢 首先这是一个好问题。其次回答这个问题也很简单。GAP锁的目的是为了防止同一事务的两次当前读出现幻读的情况。而组合五id是主键组合六id是unique键都能够保证唯一性。一个等值查询最多只能返回一条记录而且新的相同取值的记录一定不会在新插入进来因此也就避免了GAP锁的使用。其实针对此问题还有一个更深入的问题如果组合五、组合六下针对SQLselect * from t1 where id 10 for update; 第一次查询没有找到满足查询条件的记录那么GAP锁是否还能够省略此问题留给大家思考。 结论Repeatable Read隔离级别下id列上有一个非唯一索引对应SQLdelete from t1 where id 10; 首先通过id索引定位到第一条满足查询条件的记录加记录上的X锁加GAP上的GAP锁然后加主键聚簇索引上的记录X锁然后返回然后读取下一条重复进行。直至进行到第一条不满足条件的记录[11,f]此时不需要加记录X锁但是仍旧需要加GAP锁最后返回结束。 组合八id无索引RR 组合八Repeatable Read隔离级别下的最后一种情况id列上没有索引。此时SQLdelete 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的介绍可参考我之前的一篇博客MySQLInnoDB semi-consitent read原理及实现分析 。 结论在Repeatable Read隔离级别下如果进行全表扫描的当前读那么会锁上表中的所有记录同时会锁上聚簇索引内的所有GAP杜绝所有的并发 更新/删除/插入 操作。当然也可以通过触发semi-consistent read来缓解加锁开销与并发影响但是semi-consistent read本身也会带来其他问题不建议使用。 组合九Serializable 针对前面提到的简单的SQL最后一个情况Serializable隔离级别。对于SQL2delete from t1 where id 10; 来说Serializable隔离级别与Repeatable Read隔离级别完全一致因此不做介绍。 Serializable隔离级别影响的是SQL1select * from t1 where id 10; 这条SQL在RCRR隔离级别下都是快照读不加锁。但是在Serializable隔离级别SQL1会加读锁也就是说快照读不复存在MVCC并发控制降级为Lock-Based CC。 结论在MySQL/InnoDB中所谓的读不加锁并不适用于所有的情况而是隔离级别相关的。Serializable隔离级别读不加锁就不再成立所有的读操作都是当前读。 一条复杂的SQL 写到这里其实MySQL的加锁实现也已经介绍的八八九九。只要将本文上面的分析思路大部分的SQL都能分析出其会加哪些锁。而这里再来看一个稍微复杂点的SQL用于说明MySQL加锁的另外一个逻辑。SQL用例如下 如图中的SQL会加什么锁假定在Repeatable Read隔离级别下 (Read Committed隔离级别下的加锁情况留给读者分析。)同时假设SQL走的是idx_t1_pu索引。 在详细分析这条SQL的加锁情况前还需要有一个知识储备那就是一个SQL中的where条件如何拆分具体的介绍建议阅读我之前的一篇文章SQL中的where条件在数据库中提取与应用浅析 。在这里我直接给出分析后的结果 Index keypubtime 1 and puptime 20。此条件用于确定SQL在idx_t1_pu索引上的查询范围。 Index Filteruserid ‘hdc’ 。此条件可以在idx_t1_pu索引上进行过滤但不属于Index Key。 Table Filtercomment 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 PushdownSemi-Consistent Read) 了解死锁产生的原因及分析的方法 (加锁顺序不一致分析每个SQL的加锁顺序) 有了这些知识点再加上适当的实战经验全面掌控MySQL/InnoDB的加锁规则当不在话下。 文转载自 http://hedengcheng.com/?p771 扩展阅读 并发编程含义 http://hedengcheng.com/?p803 mysql行级别锁测试 http://blog.csdn.net/lengzijian/article/details/7234909 转载于:https://www.cnblogs.com/zy-jiayou/p/7428835.html
