网站备案都审核什么资料,怎么做企业曝光引流网站,wordpress 更改目录权限,mysql 存储wordpress前言
我们都知道事务的几种性质#xff0c;数据库为了维护这些性质#xff0c;尤其是一致性和隔离性#xff0c;一般使用加锁这种方式。同时数据库又是个高并发的应用#xff0c;同一时间会有大量的并发访问#xff0c;如果加锁过度#xff0c;会极大的降低并发处理能力…前言
我们都知道事务的几种性质数据库为了维护这些性质尤其是一致性和隔离性一般使用加锁这种方式。同时数据库又是个高并发的应用同一时间会有大量的并发访问如果加锁过度会极大的降低并发处理能力。所以对于加锁的处理可以说就是数据库对于事务处理的精髓所在。这里通过分析MySQL中InnoDB引擎的加锁机制来抛砖引玉让读者更好的理解在事务处理中数据库到底做了什么。
一次封锁or两段锁
因为有大量的并发访问为了预防死锁一般应用中推荐使用一次封锁法就是在方法的开始阶段已经预先知道会用到哪些数据然后全部锁住在方法运行之后再全部解锁。这种方式可以有效的避免循环死锁但在数据库中却不适用因为在事务开始阶段数据库并不知道会用到哪些数据。 数据库遵循的是两段锁协议将事务分成两个阶段加锁阶段和解锁阶段所以叫两段锁
加锁阶段在该阶段可以进行加锁操作。在对任何数据进行读操作之前要申请并获得S锁共享锁其它事务可以继续加共享锁但不能加排它锁在进行写操作之前要申请并获得X锁排它锁其它事务不能再获得任何锁。加锁不成功则事务进入等待状态直到加锁成功才继续执行。
解锁阶段当事务释放了一个封锁以后事务进入解锁阶段在该阶段只能进行解锁操作不能再进行加锁操作。
事务加锁/解锁处理begininsert into test …加insert对应的锁update test set…加update对应的锁delete from test …加delete对应的锁commit;事务提交时同时释放insert、update、delete对应的锁
这种方式虽然无法避免死锁但是两段锁协议可以保证事务的并发调度是串行化串行化很重要尤其是在数据恢复和备份的时候的。
事务中的加锁方式
事务的四种隔离级别
在数据库操作中为了有效保证并发读取数据的正确性提出的事务隔离级别。我们的数据库锁也是为了构建这些隔离级别存在的。
隔离级别脏读Dirty Read不可重复读NonRepeatable Read幻读Phantom Read未提交读Read uncommitted可能可能可能已提交读Read committed不可能可能可能可重复读Repeatable read不可能不可能可能可串行化Serializable 不可能不可能不可能
未提交读(Read Uncommitted)允许脏读也就是可能读取到其他会话中未提交事务修改的数据
提交读(Read Committed)只能读取到已经提交的数据。Oracle等多数数据库默认都是该级别 (不重复读)
可重复读(Repeated Read)可重复读。在同一个事务内的查询都是事务开始时刻一致的InnoDB默认级别。在SQL标准中该隔离级别消除了不可重复读但是还存在幻象读
串行读(Serializable)完全串行化的读每次读都需要获得表级共享锁读写相互都会阻塞 Read Uncommitted这种级别数据库一般都不会用而且任何操作都不会加锁这里就不讨论了。
MySQL中锁的种类
MySQL中锁的种类很多有常见的表锁和行锁也有新加入的Metadata Lock等等,表锁是对一整张表加锁虽然可分为读锁和写锁但毕竟是锁住整张表会导致并发能力下降一般是做ddl处理时使用。
行锁则是锁住数据行这种加锁方法比较复杂但是由于只锁住有限的数据对于其它数据不加限制所以并发能力强MySQL一般都是用行锁来处理并发事务。这里主要讨论的也就是行锁。
Read Committed读取提交内容
在RC级别中数据的读取都是不加锁的但是数据的写入、修改和删除是需要加锁的。效果如下
MySQL show create table class_teacher
Table: class_teacher
Create Table: CREATE TABLE class_teacher (id int(11) NOT NULL AUTO_INCREMENT,class_name varchar(100) COLLATE utf8mb4_unicode_ci NOT NULL,teacher_id int(11) NOT NULL,PRIMARY KEY (id),KEY idx_teacher_id (teacher_id)
) ENGINEInnoDB AUTO_INCREMENT5 DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci
1 row in set (0.02 sec)
MySQL select * from class_teacher;
------------------------------
| id | class_name | teacher_id |
------------------------------
| 1 | 初三一班 | 1 |
| 3 | 初二一班 | 2 |
| 4 | 初二二班 | 2 |
------------------------------由于MySQL的InnoDB默认是使用的RR级别所以我们先要将该session开启成RC级别并且设置binlog的模式
SET session transaction isolation level read committed; SET SESSION binlog_format ‘ROW’;或者是MIXED
事务A事务Bbegin;begin;update class_teacher set class_name‘初三二班’ where teacher_id1;update class_teacher set class_name‘初三三班’ where teacher_id1;ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transactioncommit;
为了防止并发过程中的修改冲突事务A中MySQL给teacher_id1的数据行加锁并一直不commit释放锁那么事务B也就一直拿不到该行锁wait直到超时。
这时我们要注意到teacher_id是有索引的如果是没有索引的class_name呢
update class_teacher set teacher_id3 where class_name ‘初三一班’;
那么MySQL会给整张表的所有数据行的加行锁。这里听起来有点不可思议但是当sql运行的过程中MySQL并不知道哪些数据行是 class_name 初三一班’的没有索引嘛如果一个条件无法通过索引快速过滤存储引擎层面就会将所有记录加锁后返回再由MySQL Server层进行过滤。
InnoDB的行锁是基于索引实现的如果查询没有命中任何一个索引就会锁住整张表阻塞其他查询。
但在实际使用过程当中MySQL做了一些改进在MySQL Server过滤条件发现不满足后会调用unlock_row方法把不满足条件的记录释放锁 (违背了二段锁协议的约束)。这样做保证了最后只会持有满足条件记录上的锁但是每条记录的加锁操作还是不能省略的。可见即使是MySQL为了效率也是会违反规范的。参见《高性能MySQL》中文第三版p181
这种情况同样适用于MySQL的默认隔离级别RR。所以对一个数据量很大的表做批量修改的时候如果无法使用相应的索引MySQL Server过滤数据的的时候特别慢就会出现虽然没有修改某些行的数据但是它们还是被锁住了的现象。
Repeatable Read可重读
这是MySQL中InnoDB默认的隔离级别。我们姑且分“读”和“写”两个模块来讲解。
读
读就是可重读可重读这个概念是一事务的多个实例在并发读取数据时会看到同样的数据行有点抽象我们来看一下效果。
RC不可重读模式下的展现
事务B修改id1的数据提交之后事务A同样的查询后一次和前一次的结果不一样这就是不可重读重新读取产生的结果不一样。 这就很可能带来一些问题那么我们来看看在RR级别中MySQL的表现 我们注意到当teacher_id1时事务A先做了一次读取事务B中间修改了id1的数据并commit之后事务A第二次读到的数据和第一次完全相同。所以说它是可重读的。那么MySQL是怎么做到的呢这里姑且卖个关子我们往下看。
不可重复读和幻读的区别
很多人容易搞混不可重复读和幻读确实这两者有些相似。但不可重复读重点在于update和delete而幻读的重点在于insert。
如果使用锁机制来实现这两种隔离级别在可重复读中该sql第一次读取到数据后就将这些数据加锁其它事务无法修改这些数据就可以实现可重复读了。但这种方法却无法锁住insert的数据所以当事务A先前读取了数据或者修改了全部数据事务B还是可以insert数据提交这时事务A就会发现莫名其妙多了一条之前没有的数据这就是幻读不能通过行锁来避免。需要Serializable隔离级别 读用读锁写用写锁读锁和写锁互斥这么做可以有效的避免幻读、不可重复读、脏读等问题但会极大的降低数据库的并发能力。
所以说不可重复读和幻读最大的区别就在于如何通过锁机制来解决他们产生的问题。
上文说的是使用悲观锁机制来处理这两种问题但是MySQL、ORACLE、PostgreSQL等成熟的数据库出于性能考虑都是使用了以乐观锁为理论基础的MVCC多版本并发控制来避免这两种问题。
悲观锁和乐观锁
悲观锁 正如其名它指的是对数据被外界包括本系统当前的其他事务以及来自外部系统的事务处理修改持保守态度因此在整个数据处理过程中将数据处于锁定状态。悲观锁的实现往往依靠数据库提供的锁机制也只有数据库层提供的锁机制才能真正保证数据访问的排他性否则即使在本系统中实现了加锁机制也无法保证外部系统不会修改数据。
在悲观锁的情况下为了保证事务的隔离性就需要一致性锁定读。读取数据时给加锁其它事务无法修改这些数据。修改删除数据时也要加锁其它事务无法读取这些数据。
乐观锁 相对悲观锁而言乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销特别是对长事务而言这样的开销往往无法承受。
而乐观锁机制在一定程度上解决了这个问题。乐观锁大多是基于数据版本 Version 记录机制实现。何谓数据版本即为数据增加一个版本标识在基于数据库表的版本解决方案中一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时将此版本号一同读出之后更新时对此版本号加一。此时将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对如果提交的数据版本号大于数据库表当前版本号则予以更新否则认为是过期数据。
要说明的是MVCC的实现没有固定的规范每个数据库都会有不同的实现方式这里讨论的是InnoDB的MVCC。
MVCC在MySQL的InnoDB中的实现
在InnoDB中会在每行数据后添加两个额外的隐藏的值来实现MVCC这两个值一个记录这行数据何时被创建另外一个记录这行数据何时过期或者被删除。 在实际操作中存储的并不是时间而是事务的版本号每开启一个新事务事务的版本号就会递增。 在可重读Repeatable reads事务隔离级别下
SELECT时读取创建版本号当前事务版本号删除版本号为空或当前事务版本号。INSERT时保存当前事务版本号为行的创建版本号DELETE时保存当前事务版本号为行的删除版本号UPDATE时插入一条新纪录保存当前事务版本号为行创建版本号同时保存当前事务版本号到原来删除的行
通过MVCC虽然每行记录都需要额外的存储空间更多的行检查工作以及一些额外的维护工作但可以减少锁的使用大多数读操作都不用加锁读数据操作很简单性能很好并且也能保证只会读取到符合标准的行也只锁住必要行。
我们不管从数据库方面的教课书中学到还是从网络上看到大都是上文中事务的四种隔离级别这一模块列出的意思RR级别是可重复读的但无法解决幻读而只有在Serializable级别才能解决幻读。于是我就加了一个事务C来展示效果。在事务C中添加了一条teacher_id1的数据commitRR级别中应该会有幻读现象事务A在查询teacher_id1的数据时会读到事务C新加的数据。但是测试后发现在MySQL中是不存在这种情况的在事务C提交后事务A还是不会读到这条数据。可见在MySQL的RR级别中是解决了幻读的读问题的。
读问题解决了根据MVCC的定义并发提交数据时会出现冲突那么冲突时如何解决呢我们再来看看InnoDB中RR级别对于写数据的处理。
“读”与“读”的区别
可能有读者会疑惑事务的隔离级别其实都是对于读数据的定义但到了这里就被拆成了读和写两个模块来讲解。这主要是因为MySQL中的读和事务隔离级别中的读是不一样的。
我们且看在RR级别中通过MVCC机制虽然让数据变得可重复读但我们读到的数据可能是历史数据是不及时的数据不是数据库当前的数据这在一些对于数据的时效特别敏感的业务中就很可能出问题。
对于这种读取历史数据的方式我们叫它快照读 (snapshot read)而读取数据库当前版本数据的方式叫当前读 (current read)。很显然在MVCC中
快照读就是select select * from table …;
当前读特殊的读操作插入/更新/删除操作属于当前读处理的都是当前的数据需要加锁。 select * from table where ? lock in share mode; select * from table where ? for update; insert; update ; delete;
事务的隔离级别实际上都是定义了当前读的级别MySQL为了减少锁处理包括等待其它锁的时间提升并发能力引入了快照读的概念使得select不用加锁。而update、insert这些“当前读”就需要另外的模块来解决了。
写“当前读”
事务的隔离级别中虽然只定义了读数据的要求实际上这也可以说是写数据的要求。上文的“读”实际是讲的快照读而这里说的“写”就是当前读了。
为了解决当前读中的幻读问题MySQL事务使用了Next-Key锁。
Next-Key锁临键锁
Next-Key锁是行锁和GAP间隙锁的合并行锁上文已经介绍了接下来说下GAP间隙锁。
行锁可以防止不同事务版本的数据修改提交时造成数据冲突的情况。但如何避免别的事务插入数据就成了问题。我们可以看看RR级别和RC级别的对比
RC级别
RR级别 通过对比我们可以发现在RC级别中事务A修改了所有teacher_id30的数据但是当事务Binsert进新数据后事务A发现莫名其妙多了一行teacher_id30的数据而且没有被之前的update语句所修改这就是“当前读”的幻读。
RR级别中事务A在update后加锁事务B无法插入新数据这样事务A在update前后读的数据保持一致避免了幻读。这个锁就是Gap锁。
MySQL是这么实现的
在class_teacher这张表中teacher_id是个索引那么它就会维护一套B树的数据关系为了简化我们用链表结构来表达实际上是个树形结构但原理相同
如图所示InnoDB使用的是聚集索引teacher_id身为二级索引就要维护一个索引字段和主键id的树状结构这里用链表形式表现并保持顺序排列。
Innodb将这段数据分成几个个区间
(negative infinity, 5],(5,30],(30,positive infinity)
update class_teacher set class_name‘初三四班’ where teacher_id30;
不仅用行锁锁住了相应的数据行同时也在30两边的区间5,30]和30positive infinity都加入了gap锁。这样事务B就无法在这个两个区间insert进新数据。
受限于这种实现方式Innodb很多时候会锁住不需要锁的区间。如下所示 update的teacher_id20是在(530]区间即使没有修改任何数据Innodb也会在这个区间加gap锁而其它区间不会影响事务C正常插入。
如果使用的是没有索引的字段比如
update class_teacher set teacher_id7 where class_name‘初三八班’;
那么会给全表加入gap锁即使没有匹配到任何数据。同时它不能像上文中行锁一样经过MySQL Server过滤自动解除不满足条件的锁因为没有索引则这些字段也就没有排序也就没有区间。除非该事务提交否则其它事务无法插入任何数据。
行锁防止别的事务修改或删除GAP锁防止别的事务新增行锁和GAP锁结合形成的的Next-Key锁共同解决了RR级别在写数据时的幻读问题。
Serializable
这个级别很简单读加共享锁写加排他锁读写互斥。使用的悲观锁的理论实现简单数据更加安全但是并发能力非常差。如果你的业务并发的特别少或者没有并发同时又要求数据及时可靠的话可以使用这种模式。
这里要吐槽一句不要看到select就说不会加锁了在Serializable这个级别还是会加锁的
文章转自https://tech.meituan.com/innodb-lock.html
总结
隔离级别RR、RC下 1快照读select * from …不会加锁写操作会加锁。 2快照读通过MVCC在一定程度上避免幻读某些情况下仍可能出现幻读参考MVCC能否解决幻读。隔离级别RR的在当前读select … lock in share mode 、select … for update、insert、update、delect通过临键锁next-key来避免幻读隔离级别Serializable读加共享锁写加排他锁读写互斥。使用的悲观锁的理论实现简单数据更加安全但是并发能力非常差。select不显示加锁时select … lock in share mode 、select … for update除了Serializable级别其它级别不会加锁在可重复读和串行级别下存在间隙锁其它两个级别不存在该锁
