关于mySql 中乐观锁与读已提交（事务隔离级别）的搭配使用问题！！求大神带飞！

Posted

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了关于mySql 中乐观锁与读已提交（事务隔离级别）的搭配使用问题！！求大神带飞！相关的知识，希望对你有一定的参考价值。

最近，一个同事向我们分享了他最近一段时间来对事务的学习成果，我们（都是菜鸟~）就我们当前系统的数据有了疑问，我们当前使用的是乐观锁的形式来保证数据稳定，具体就是版本号的形式。顺便问了一下我们老大，他说我们数据库的隔离级别是读已提交（Read Committed），然后我们就 如果使用乐观锁的话，隔离级别是读未提交还是读已提交的问题产生疑问，这两者是否有区别（从业务层面），如果使用读已提交，是否合理，数据最后能否保证正确等问题。求大神能给解答~万分感谢。咳咳，只说结果的恕我无法理解。。

术式之后皆为逻辑，一切皆为需求和实现。希望此文能从需求、现状和解决方式的角度帮大家理解隔离级别。


隔离级别的产生

在串型执行的条件下，数据修改的顺序是固定的、可预期的结果，但是并发执行的情况下，数据的修改是不可预期的，也不固定，为了实现数据修改在并发执行的情况下得到一个固定、可预期的结果，由此产生了隔离级别。

所以隔离级别的作用是用来平衡数据库并发访问与数据一致性的方法。


事务的4种隔离级别

READ UNCOMMITTED       未提交读，可以读取未提交的数据。READ COMMITTED         已提交读，对于锁定读(select with for update 或者 for share)、update 和 delete 语句，                       InnoDB 仅锁定索引记录，而不锁定它们之间的间隙，因此允许在锁定的记录旁边自由插入新记录。                       Gap locking 仅用于外键约束检查和重复键检查。REPEATABLE READ        可重复读，事务中的一致性读取读取的是事务第一次读取所建立的快照。SERIALIZABLE           序列化

在了解了 4 种隔离级别的需求后，在采用锁控制隔离级别的基础上，我们需要了解加锁的对象(数据本身&间隙)，以及了解整个数据范围的全集组成。


数据范围全集组成

SQL 语句根据条件判断不需要扫描的数据范围（不加锁）；

SQL 语句根据条件扫描到的可能需要加锁的数据范围；

以单个数据范围为例，数据范围全集包含：（数据范围不一定是连续的值，也可能是间隔的值组成）

1. 数据已经填充了整个数据范围：（被完全填充的数据范围，不存在数据间隙）

    整形，对值具有唯一约束条件的数据范围 1～5 ，

    已有数据1、2、3、4、5，此时数据范围已被完全填充；

    整形，对值具有唯一约束条件的数据范围 1 和 5 ，

    已有数据1、5，此时数据范围已被完全填充； 

    2. 数据填充了部分数据范围：（未被完全填充的数据范围，是存在数据间隙）

    整形的数据范围 1～5 ，

    已有数据 1、2、3、4、5，但是因为没有唯一约束，

    所以数据范围可以继续被 1～5 的数据重复填充；

    整形，具有唯一约束条件的数据范围 1～5 ，

    已有数据 2，5，此时数据范围未被完全填充，还可以填充 1、3、4 ；

    3. 数据范围内没有任何数据（存在间隙）

    如下：

    整形的数据范围 1～5 ，数据范围内当前没有任何数据。

    在了解了数据全集的组成后，我们再来看看事务并发时，会带来的问题。

    无控制的并发所带来的问题

    并发事务如果不加以控制的话会带来一些问题，主要包括以下几种情况。

    1. 范围内已有数据更改导致的：

    更新丢失：当多个事务选择了同一行，然后基于最初选定的值更新该行时，

    由于每个事物不知道其他事务的存在，最后的更新就会覆盖其他事务所做的更新；

    脏读： 一个事务正在对一条记录做修改，这个事务完成并提交前，这条记录就处于不一致状态。

    这时，另外一个事务也来读取同一条记录，如果不加控制，

    第二个事务读取了这些“脏”数据，并据此做了进一步的处理，就会产生提交的数据依赖关系。

    这种现象就叫“脏读”。

    2. 范围内数据量发生了变化导致：

    不可重复读：一个事务在读取某些数据后的某个时间，再次读取以前读过的数据，

    却发现其读出的数据已经发生了改变，或者某些记录已经被删除了。

    这种现象就叫“不可重复读”。

    幻读：一个事务按相同的查询条件重新读取以前检索过的数据，

    却发现其他事务插入了满足其查询条件的新数据，这种现象称为“幻读”。

    可以简单的认为满足条件的数据量变化了。

    因为无控制的并发会带来一系列的问题，这些问题会导致无法满足我们所需要的结果。因此我们需要控制并发，以实现我们所期望的结果(隔离级别)。

    mysql 隔离级别的实现

    InnoDB 通过加锁的策略来支持这些隔离级别。

    行锁包含：

    Record Locks

    索引记录锁，索引记录锁始终锁定索引记录，即使表中未定义索引，

    这种情况下，InnoDB 创建一个隐藏的聚簇索引，并使用该索引进行记录锁定。

    Gap Locks

    间隙锁是索引记录之间的间隙上的锁，或者对第一条记录之前或者最后一条记录之后的锁。

    间隙锁是性能和并发之间权衡的一部分。

    对于无间隙的数据范围不需要间隙锁，因为没有间隙。

    Next-Key Locks

    索引记录上的记录锁和索引记录之前的 gap lock 的组合。

    假设索引包含 10、11、13 和 20。

    可能的next-key locks包括以下间隔，其中圆括号表示不包含间隔端点，方括号表示包含端点：

    (负无穷大, 10]    (10, 11]    (11, 13]    (13, 20]    (20, 正无穷大)        对于最后一个间隔，next-key将会锁定索引中最大值的上方，


    左右滑动进行查看

    "上确界"伪记录的值高于索引中任何实际值。

    上确界不是一个真正的索引记录，因此，实际上，这个 next-key 只锁定最大索引值之后的间隙。

    基于此，当获取的数据范围中，数据已填充了所有的数据范围，那么此时是不存在间隙的，也就不需要 gap lock。

    对于数据范围内存在间隙的，需要根据隔离级别确认是否对间隙加锁。

    默认的 REPEATABLE READ 隔离级别，为了保证可重复读，除了对数据本身加锁以外，还需要对数据间隙加锁。

    READ COMMITTED 已提交读，不匹配行的记录锁在 MySQL 评估了 where 条件后释放。

    对于 update 语句，InnoDB 执行 "semi-consistent" 读取，这样它会将最新提交的版本返回到 MySQL，

    以便 MySQL 可以确定该行是否与 update 的 where 条件相匹配。

    总结&延展：

    唯一索引存在唯一约束，所以变更后的数据若违反了唯一约束的原则，则会失败。

    当 where 条件使用二级索引筛选数据时，会对二级索引命中的条目和对应的聚簇索引都加锁；所以其他事务变更命中加锁的聚簇索引时，都会等待锁。

    行锁的增加是一行一行增加的，所以可能导致并发情况下死锁的发生。

    例如，

    在 session A 对符合条件的某聚簇索引加锁时，可能 session B 已持有该聚簇索引的 Record Locks，而 session B 正在等待 session A 已持有的某聚簇索引的 Record Locks。

    session A 和 session B 是通过两个不相干的二级索引定位到的聚簇索引。

    session A 通过索引 idA，session B通过索引 idB 。

    当 where 条件获取的数据无间隙时，无论隔离级别为 rc 或 rr，都不会存在间隙锁。

    比如通过唯一索引获取到了已完全填充的数据范围，此时不需要间隙锁。

    间隙锁的目的在于阻止数据插入间隙，所以无论是通过 insert 或 update 变更导致的间隙内数据的存在，都会被阻止。

    rc 隔离级别模式下，查询和索引扫描将禁用 gap locking，此时 gap locking 仅用于外键约束检查和重复键检查（主要是唯一性检查）。

    rr 模式下，为了防止幻读，会加上 Gap Locks。

    事务中，SQL 开始则加锁，事务结束才释放锁。

    就锁类型而言，应该有优化锁，锁升级等，例如rr模式未使用索引查询的情况下，是否可以直接升级为表锁。

    就锁的应用场景而言，在回放场景中，如果确定事务可并发，则可以考虑不加锁，加快回放速度。

    锁只是并发控制的一种粒度，只是一个很小的部分：

    从不同场景下是否需要控制并发，(已知无交集且有序的数据的变更，MySQL 的 MTS 相同前置事务的多事务并发回放)

    并发控制的粒度，(锁是一种逻辑粒度，可能还存在物理层和其他逻辑粒度或方式)

    相同粒度下的优化，(锁本身存在优化，如IX、IS类型的优化锁)

    粒度加载的安全&性能(如获取行锁前，先获取页锁，页锁在执行获取行锁操作后即释放，无论是否获取成功)等多个层次去思考并发这玩意。

 参考技术A 在read uncommitted(未提交读)级别中，事务中的修改，即使没有提交，对其他事务也是可见的。事务可以读取未提交的数据，这种也可以叫脏读，这个级别其实会导致很多问题，从性能上讲，未提交读不会比其他级别好太多，但却缺乏其他级别的好处，除非真的非常有必要，在实际中一般不使用的。

mysql有个多版本控制MVCC，可以认为MVCC是行级锁的一个变种，但他在很多情况下避免了加锁操作，因此开销更低。MVCC实际上是乐观并发控制的，通过每行的记录后面保存两个隐藏的列实现，一个是创建时间，一个是删除时间，当然实际存储的不是时间值，而是版本号。

MVCC只在repeatable read和read committed两个级别下工作，其他隔离级别都和MVCC不兼容，因为read uncommitted总是读到最新数据，而不是符合当前事务版本的数据行。
综上所述，乐观锁是和读已提交搭配使用是可以的 参考技术B

大部分 都是读已提交(read committed),

未提交读是无意义的.事务本来就是保证一致性的

事务进行中本身就不知道结果是成功还是失败

只有进行完毕才算是真正的写入数据库, Read unCommitted(脏读)所以实际运用很少,而且会

导致很多问题

很多时候,你可以自己 实践 一下 :

$db = mysqli_connect(...省略..);
$db->autocommit(false); 
$sql= "update table set value = value + 10 where id = 1";
$db->query($sql); //执行语句
sleep(20);//延迟20秒
$db->commit(); //提交
    mysqli_close($db);
    
    
    //上面进行事务的同时,你select 该行,看看 值是 提交前还是提交后
    //自己实践就出真理,记得更牢,说太多理论,反而听的不清不楚

追问

嗯。您说的我明白，主要是同事说读未提交比读已提交在数据库中消费的性能更小，由此我们才纠结要不要换的。因为我们讨论了十来分钟，实在是没有考虑出会出问题的实际业务场景。因为我们了解的不够，所以感觉使用读未提交能提高数据库性能且并不影响使用。。

深入理解mysql锁与事务隔离级别

一、锁

1、锁的定义

    锁即是一种用来协调多线程或进程并发使用同一共享资源的机制

2、锁的分类

  •  从性能上分类:乐观锁和悲观锁
  • 从数据库操作类型上分类：读锁和写锁
  • 从操作粒度上分类：表锁和行锁

2.1 从性能上分类

2.1.1 乐观锁
    乐观锁顾名思义就是操作的时候很乐观，认为操作不会产生并发问题(不会有其他线程对数据进行修改），因此不会上锁。但是会在更新时判断其他线程再这之前有没有对数据进行修改，一般会使用版本号机制或CAS算法实现。
2.1.1.1 版本号机制
 实现方式：
  • 取出记录时，获取当前version
  • 更新时，带上这个version
  • 执行更新时，set version = newVersion where version = oldVersion
  • 如果version不对，就更新失败
version可以自定义，也可以使用时间戳来作为版本编号
示例SQL：
update table set name = \'anna\',version = version+1 where id = #{id} and version = #{version}
 
 
2.1.1.2 CAS算法
    乐观锁的另一种技术，当多个线程尝试使用CAS同时更新同一个变量时，只有其中一个线程能更新表变量的值，而其他线程都失败，失败的线程并不会呗挂起，而是被告知在这次竞争中失败，并可以再次尝试。
CAS操作中包含三个操作数：
  • 需要读写的内存位置V
  • 进行比较的预期原值A
  • 拟写入的新值B
如果内存位置V的值与预期原值A匹配，则将B写入内存位置V中替代A，如果预期原值A不匹配则不做任何操作。无论那种情况，他都会在CAS指令之前返回该位置的值（在CAS的一些特殊情况下仅返回CAS是否成功，而不提取当前值)。这其实和乐观锁的冲突检查+数据更新的原理时一致的。
2.1.2 悲观锁
    总是假设最坏的情况，每次取数据都会认为其他线程会修改，所以都会加锁。一旦加锁，不同线程同时执行的时，只能有一个线程执行，其他线程在入口出等待，知道锁被释放。
悲观锁在Mysql和JAVA中被广泛应用
  •     MYSQL的读锁、写锁、行锁等 
  •     Java的synchronized关键字
使用建议：
    读得多，冲突几率小，使用乐观锁
    写的锁，冲突几率大，使用悲观锁

2.2 从数据库操作类型上分类

2.2.1 读锁
    读锁在加锁时允许其他事务进行查询操作，但不允许进行修改操作，即共享锁。
2.2.2 写锁
    写锁在加锁时则不允许其他事务进行任何操作，即排他锁。

2.3 从操作粒度上分类

2.3.1 表锁
    顾名思义，会将整个表加锁，这种方式加锁粒度大，加锁块、开销小，不会产生死锁。但是并发执行情况下效率较低、容易发生锁冲突。
2.3.2 行锁
    行锁会对被操作的数据行进行加锁，这种方式加锁粒度小、加锁慢、开销大，可能会产生死锁。但是并发执行情况下效率高，不容易发生锁冲突。
    innodb中的行锁时针对索引加锁而非针对记录。如果索引失效，就会从行锁升级为表锁。
在Mysql中MyISAM的引擎仅支持表锁，每次进行查询操作都会对表加读锁，进行修改操作则加写锁。MyISAM并不支持事务和行锁，而innodb支持行级锁和事务，这也是MyISAM和Innodb最大的不同。

二、事务

1、事务的定义

    事务时由一组SQL语句组成的逻辑处理单元。

2、事务的特性

    事务具有四种特性：原子性、一致性、隔离性、持久性。
  • 原子性：事务中所有操作应具有原子性，即要么都执行要么都不执行
  • 一致性：指操作执行前后的数据具备一致性。这意味着，所有相关的数据规则都必须应用于事务的修改，以保证数据的完整性。事务结束时，所有的数据结构也都必须是正确的。
  • 隔离性：每个事务都有其独立的环境，事务的的中间状态不为外界可见，反之亦然。
  • 持久性：当事务提交之后，它对数据库数据的改变具有持久性，即便数据库宕机重启后数据库的数据状态应该依然是事务提交之后的结果。

3、并发事务处理带来的问题

  • 更新丢失：当两个或多个事务选择同一行，然后基于最初选定的值更新该行时，由于每个事务都不知道其他事务的存在，就会发生更新丢失的问题-最后的更新覆盖的有其他事务所做的更新。
  • 脏读：事务读取到了其他事务修改但未提交的的值，而之后那个事务进行了回滚，那么当前事务所读取到的数据就是脏数据，不符合事务的一致性。
  • 不可重复读：当前事务在一开始读取了一行数据，而在那之后另一个事务提交了一个对于该行的更新，那么当此事务再次去读取同一行数据时，读取到的结果和第一次的不同、或则这一条记录已被删除，这种现象就叫做不可重复读。
    也就是说事务读取到了其他事务已提交的数据，不符合隔离性。
  • 幻读：事务A读取到了事务B已提交的新增的数据，不符合隔离性

4、事务的隔离级别

    为了解决并发事务处理所带来的问题，mysql提供了4种事务隔离级别以供我们选择。
  • 读未提交(read uncommit):可以读取到事务未提交的修改
  • 读已提交(read commit):可以读取到事务已提交的修改
  • 可重复读(repeatable read):事务进行中不会读取到其他事务已提交的修改，只会使用第一次查询时所获得的快照结果。这里使用到了MVCC(多版本并发控制)机制来达到这个效果。
  • 串行化(Serializable)：将事务转化为串行的形式来执行，该级别会进行锁表，因此不会出现幻读的情况，这种隔离界别的并发性极低，开发种很少会用到。
    数据库的事务隔离级别越严格，那么并发所带来的副作用就越小，但是并发执行的效率也就越低，因为事务隔离级别就是在一定程度上使事务“串行化”进行，这显然与“并发”相矛盾。
    所以应该合理的去选择事务隔离级别，根据业务场景对于数据的敏感程度进行选择。
 
间隙锁：使用间隙锁可以在可重复读的隔离级别下避免幻读，使用下面SQL语句
update account set name = \'tufeu\' where id>=5  and id < 7;
在事务开头执行这一语句，可以使得其他事务无法在当前事务未提交前在id为5到7之间插入数据，这就是间隙锁
当然如果你不想真的修改数据的话，请保证间隙锁范围内没有数据。
 
 
在seesion_1种使用间隙锁
在session_2种插入新数据因为id自增所以新id为6，在间隙锁范围内，被阻塞导致超时，插入失败。
不过由于大部分场景下不需要处理幻读的情况，所以平时要尽量避免间隙读，因为这样的确会降低并发效率
MVCC机制：
    mvcc机制底层由undo log实现，这里以一种较为简单的方式说明机制
首先要明确每个事务都有一个自己的id,事务的id只有在事务执行第一条sql语句时才会分配，mysql的事务id分配严格按照事务的创建顺序来进行。
我们可以看作每一条数据都有两个隐藏的字段创建事务id和删除事务id（可为空）
当我们修改一条数据的时候，不会直接修改，而是新增一条修改过后的数据id和原数据一致（这里是假设不是真实实现，不考虑id重复这个问题）
当我们删除的时候，会将当前做删除操作的事务id记录再”删除事务id“列上
当我们查询一条记录是，会创建一个查询快照，记录此刻的最大已提交事务id。
当我们再次查询的时候会在mysql底层带上过滤条件，创建事务id<=max(当前事务id,快照点已提交最大事务id) and 删除事务id>max(当前事务id，快照点已提交最大事务id）
查询结果不一定唯一，以创建事务id最大的那个为准。
id name balacne create_id del_id
1  a	100	11
2  b	200	12　　　　12
3  c 	300	12
1  a	120	14
 
比如上面这几行数据，假如我们事务id为11 和 12 新增前三条数据，然后新开一个事务id为13的事务，进行查询操作select * form account,的到一个快照，并获得当前的最大已提交事务id为12，不去提交13，新创建一个事务id14，修改id为1的语句，这个时候，mysql会新增一条数据为修改过后的样子，有其事务创建id为14，这个时候我们用事务13去查询，查询语句回事 select * from account where 创建事务id<=max(当前事务id(13)，快照点最大提交id(12)) and 删除事务id>max(当前事务id(13),快照点最大提交id(12))，如果没有删除事务id则忽略这个条件，这个时候应该可以看出我们查询出来的数据只会是第一条，因为第四条的创建事务id为14。
我们再看id为2的数据，根据上面的sql查询语句，我们可以看出他的删除事务id为12小于max（当前事务id，快照点最大提交id）所以无法查询到该数据。
 
优化建议：
  • 尽可能的让数据检索通过索引完成，避免无索引行锁升级为表锁
  • 合理设计索引，尽量缩小锁的范围
  • 极可能减少检索条件范围，避免间隙锁
  • 尽量控制事务大小，减少锁定资源量和时间长度，设计事务加锁的sql尽量放在事务最后执行
  • 尽可能使用低级别的事务隔离以提升并发效率
 
 
 
 

<wiz_tmp_tag id="wiz-table-range-border" contenteditable="false" style="display: none;">





以上是关于关于mySql 中乐观锁与读已提交（事务隔离级别）的搭配使用问题！！求大神带飞！的主要内容，如果未能解决你的问题，请参考以下文章

mysql 锁与事务的一些概念

事务隔离级别

MySql事务隔离的特点与实现

互联网项目中mysql应该选什么事务隔离级别 转

互联网项目中mysql应该选什么事务隔离级别 转

RDB | MySQL的事务隔离级别和锁的机制