修水新闻最新消息,seo网站项目讲解,昆明网站建设企业,北排建设公司官网Latch一般称为闩锁#xff08;轻量级锁#xff09;#xff0c;因为其要求锁定的时间必须非常短。在InnoDB存储引擎中#xff0c;latch又分为mutex#xff08;互斥量#xff09;和rwlock#xff08;读写锁#xff09;。 Lock的对象是事务#xff0c;用来锁定的是… Latch一般称为闩锁轻量级锁因为其要求锁定的时间必须非常短。在InnoDB存储引擎中latch又分为mutex互斥量和rwlock读写锁。 Lock的对象是事务用来锁定的是数据库中的对象如表、页、行。并且一般lock的对象仅在事务commit或rollback后进行释放不同的事务隔离级别释放时间可能不同。
1-InnoDB存储引擎中的锁
共享锁S Lock允许事务读一行数据 排他锁X Lock允许事务删除或更新一行数据 X锁和任何锁都不兼容而S锁仅和S锁兼容 X锁和S锁都是行锁 兼容是指对同一记录row锁的兼容性情况
2-行锁的算法
InnoDB存储引擎有3种行锁算法分别是Record Lock单个行记录上的锁Gap Lock间隙锁锁定一个范围但不包含记录本身Next-Key LockGap Lock Record Lock锁定一个范围并且锁定记录本身 采用Next-Key Lock的锁定技术成为Next-Key Locking。其目的是为了解决幻读phantom problem其锁定不是单个值而是一个范围是谓词锁predict lock的一种改进。例如有一个索引有10,11,13,20这四个值那么该索引可能被Next-Key Locking区间为(-∞,10]、(10,11]、(11,13]、(13,20]、(20, ∞) InnoDB存储引擎的事务默认级别是RR在该级别下其采用Next-Key Locking的方式来加锁。而在RC级别下其仅采用Record Lock。
开胃菜锁分析演示
CREATE TABLE ta (a int(10) NOT NULL,b int(10) NOT NULL,c int(10) NOT NULL,PRIMARY KEY (a)
) ENGINEInnoDB DEFAULT CHARSETutf8;insert into ta (a,b,c) values (1,3,4);
insert into ta (a,b,c) values (5,8,10);
insert into ta (a,b,c) values (10,12,13);分析表ta中有1,5,10三条记录session1首先对a5进行X锁定由于a是主键因此仅仅锁定5这个值不是锁定范围因此插入a4不会阻塞。锁定由Next-Key Lock算法降级为Record Lock提供应用的并发性。如果a列是唯一索引锁定由Next-Key Lock算法降级为Record Lock提供应用的并发性。 delete from ta where a4;删除刚才插入的记录
ALTER TABLE ta ADD INDEX index_b (b) ;执行如下5条语句 1select * from ta where a5 lock in share mode; 2insert into ta (a,b,c) values (4,7 ,44); 3insert into ta (a,b,c) values (6,11,44); 4insert into ta (a,b,c) values (6,12,44); 5insert into ta (a,b,c) values (20,3,44); 上面5条语句不能执行 解释 b8,查询到记录的主键是a5首先会锁定a5的记录X锁所以第一条阻塞由于索引b的值为3,8,12 该索引可能被Next-Key Locking区间为(-∞,3]、(3,8]、(8,12]、 (12, ∞) 虽然第二条第三条第四条第五条主键都不等于5但是b的值在[3,12]范围内因此都是阻塞的。
以下两条可以执行是因为不满足a5和b的区间[3,12]范围内。 insert into ta (a,b,c) values (100,2,44); insert into ta (a,b,c) values (101,13,44);
3-加锁分析之大餐
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锁 (排它锁)。 场景准备
SQL1select * from t1 where id 10; SQL2delete from t1 where id 10;
SQL1select操作均不加锁采用的是快照读因此在下面的讨论中就忽略了 主要讨论SQL2delete操作的加锁。
所有的加锁分析必须提前告知隔离级别和表的字段的索引情况主键唯一索引普通索引还是普通字段没有索引一切不以这些前提的分析都是瞎扯一切不以这些前提的分析都是瞎扯一切不以这些前提的分析都是瞎扯。 3.1-RCid主键
delete from t1 where id 10;// 只需要将主键上id 10的记录加上X锁即可。
表结构t1(id primary key,name) 结论id是主键时此SQL只需要在id10这条记录上加X锁即可。
3.2-RCid唯一索引
表结构t1(name primary key,id unique key) 此组合中id是unique索引而主键是name列。此时加锁的情况由于组合一有所不同。由于id是unique索引因此delete语句会选择走id列的索引进行where条件的过滤在找到id10的记录后首先会将unique索引上的id10索引记录加上X锁同时会根据读取到的name列回主键索引(聚簇索引)然后将聚簇索引上的name ‘c’ 对应的主键索引项加X锁。为什么聚簇索引上的记录也要加锁试想一下如果并发的一个SQL是通过主键索引来更新update t1 set id 100 where name ‘c’; 此时如果delete语句没有将主键索引上的记录加锁那么并发的update就会感知不到delete语句的存在违背了同一记录上的更新/删除需要串行执行的约束。 结论若id列是unique列其上有unique索引。那么SQL需要加两个X锁一个对应于id unique索引上的id 10的记录另一把锁对应于聚簇索引上的[name’c’,id10]的记录。
3.3-RCid非唯一索引 表结构t1(name primary key,id key) 相对于组合一、二组合三又发生了变化隔离级别仍旧是RC不变但是id列上的约束又降低了id列不再唯一只有一个普通的索引。假设delete from t1 where id 10; 语句仍旧选择id列上的索引进行过滤where条件那么此时会持有哪些锁 根据此图可以看到首先id列索引上满足id 10查询条件的记录均已加锁。同时这些记录对应的主键索引上的记录也都加上了锁。与组合二唯一的区别在于组合二最多只有一个满足等值查询的记录而组合三会将所有满足查询条件的记录都加锁。 结论若id列上有非唯一索引那么对应的所有满足SQL查询条件的记录都会被加锁。同时这些记录在主键索引上的记录也会被加锁。
3.4-RCid无索引
表结构t1(name primary key,id) 相对于前面三个组合这是一个比较特殊的情况。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的约束。
3.5-RRid主键
加锁同3.1
3.6-RRid唯一索引
加锁同3.2
3.7-RRid非唯一索引
表结构t1(name primary key,id key) 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树索引的有序性满足条件的项一定是连续存放的。记录[5,e]之前不会插入id10的记录[5,e]与[10,c]间可以插入[10, aa][10,c]与[10,a]间可以插入新的[10,bb],[10,cc]等[10,a]与[20,b]间可以插入满足条件的[10,ee],[10,zz]等而[20,b]之后也不会插入满足条件的记录。因此为了保证[5,e]与[10,c]间[10,c]与[10,a]间[10,a]与[20,b]不会插入新的满足条件的记录MySQL选择了用GAP锁将这三个GAP给锁起来。 Insert操作如insert [10,d]首先会定位到[5,e]与[10,c]间然后在插入前会检查这个GAP是否已经被锁上如果被锁上则Insert不能插入记录。因此通过第一遍的当前读不仅将满足条件的记录锁上 (X锁)与组合三类似。同时还是增加3把GAP锁将可能插入满足条件记录的3个GAP给锁上保证后续的Insert不能插入新的id10的记录也就杜绝了同一事务的第二次当前读出现幻象的情况。
有心的朋友看到这儿可以会问既然防止幻读需要靠GAP锁的保护为什么组合五、组合六也是RR隔离级别却不需要加GAP锁呢
首先这是一个好问题。其次回答这个问题也很简单。GAP锁的目的是为了防止同一事务的两次当前读出现幻读的情况。而组合五id是主键组合六id是unique键都能够保证唯一性。一个等值查询最多只能返回一条记录而且新的相同取值的记录一定不会在新插入进来因此也就避免了GAP锁的使用。 结论Repeatable Read隔离级别下id列上有一个非唯一索引对应SQLdelete from t1 where id 10; 首先通过id索引定位到第一条满足查询条件的记录加记录上的X锁加GAP上的GAP锁然后加主键聚簇索引上的记录X锁然后返回然后读取下一条重复进行。直至进行到第一条不满足条件的记录[20,b]此时不需要加记录X锁但是仍旧需要加GAP锁最后返回结束。
3.8-RRid无索引 Repeatable Read隔离级别下的最后一种情况id列上没有索引。此时SQLdelete from t1 where id 10; 没有其他的路径可以选择只能进行全表扫描。
表结构t1(name primary key,id) 如图这是一个很恐怖的现象。首先聚簇索引上的所有记录都被加上了X锁。其次聚簇索引每条记录间的间隙(GAP)也同时被加上了GAP锁。这个示例表只有5条记录一共需要5个记录锁6个GAP锁。试想如果表上有1000万条记录呢 在这种情况下这个表上除了不加锁的快照度其他任何加锁的并发SQL均不能执行不能更新不能删除不能插入全表被锁死。 当然跟组合四[id无索引, Read Committed]类似这个情况下MySQL也做了一些优化就是所谓的semi-consistent read。semi-consistent read开启的情况下对于不满足查询条件的记录MySQL会提前放锁。针对上面的这个用例就是除了记录[a,10][c,10]之外所有的记录锁都会被释放同时不加GAP锁。semi-consistent read如何触发要么是read committed隔离级别要么是Repeatable Read隔离级别同时设置了 innodb_locks_unsafe_for_binlog 参数。 结论在Repeatable Read隔离级别下如果进行全表扫描的当前读那么会锁上表中的所有记录同时会锁上聚簇索引内的所有GAP杜绝所有的并发 更新/删除/插入 操作。当然也可以通过触发semi-consistent read来缓解加锁开销与并发影响但是semi-consistent read本身也会带来其他问题不建议使用。
3.9-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隔离级别读不加锁就不再成立所有的读操作都是当前读。
