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

作者&投稿:戢陈 (若有异议请与网页底部的电邮联系)
"<>" mysql中什么意思~

1.根本的区别是它们遵循的基本原则
二者所遵循的基本原则是它们的主要区别:开放vs保守。SQL服务器的狭隘的,保守的存储引擎与MySQL服务器的可扩展,开放的存储引擎绝然不同。虽然你可以使用SQL服务器的Sybase引擎,但MySQL能够提供更多种的选择,如MyISAM, Heap, InnoDB, and Berkeley DB。MySQL不完全支持陌生的关键词,所以它比SQL服务器要少一些相关的数据库。同时,MySQL也缺乏一些存储程序的功能,比如MyISAM引擎联支持交换功能。
2.性能:先进的MySQL
纯粹就性能而言,MySQL是相当出色的,因为它包含一个缺省桌面格式MyISAM。MyISAM 数据库与磁盘非常地兼容而不占用过多的CPU和内存。MySQL可以运行于Windows系统而不会发生冲突,在UNIX或类似UNIX系统上运行则更好。你还可以通过使用64位处理器来获取额外的一些性能。因为MySQL在内部里很多时候都使用64位的整数处理。Yahoo!商业网站就使用MySQL作为后台数据库。

当提及软件的性能,SQL服务器的稳定性要比它的竞争对手强很多。但是,这些特性也要付出代价的。比如,必须增加额外复杂操作,磁盘存储,内存损耗等等。如果你的硬件和软件不能充分支持SQL服务器,我建议你最好选择其他如DBMS数据库,因为这样你会得到更好的结果。
3.发行费用:MySQL不全是免费,但很便宜
当提及发行的费用,这两个产品采用两种绝然不同的决策。对于SQL服务器,获取一个免费的开发费用最常的方式是购买微软的Office或者Visual Studio的费用。但是,如果你想用于商业产品的开发,你必须还要购买SQL Server Standard Edition。学校或非赢利的企业可以不考虑这一附加的费用。
4.安全功能

MySQL有一个用于改变数据的二进制日志。因为它是二进制,这一日志能够快速地从主机上复制数据到客户机上。即使服务器崩溃,这一二进制日志也会保持完整,而且复制的部分也不会受到损坏。

在SQL服务器中,你也可以记录SQL的有关查询,但这需要付出很高的代价。

安全性
这两个产品都有自己完整的安全机制。只要你遵循这些安全机制,一般程序都不会出现什么问题。这两者都使用缺省的IP端口,但是有时候很不幸,这些IP也会被一些黑客闯入。当然,你也可以自己设置这些IP端口。

恢复性:先进的SQL服务器
恢复性也是MySQL的一个特点,这主要表现在MyISAM配置中。这种方式有它固有的缺欠,如果你不慎损坏数据库,结果可能会导致所有的数据丢失。然而,对于SQL服务器而言就表现得很稳键。SQL服务器能够时刻监测数据交换点并能够把数据库损坏的过程保存下来。
供你参考,祝你好运!!!

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


隔离级别的产生

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

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


事务的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类型的优化锁)

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



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

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

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

大部分 都是读已提交(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 该行,看看 值是 提交前还是提交后
    //自己实践就出真理,记得更牢,说太多理论,反而听的不清不楚



成华区15767572405: 关于mySql 中乐观锁与读已提交(事务隔离级别)的搭配使用问题!!求大神带飞! -
謇钞奥贝: 术式之后皆为逻辑,一切皆为需求和实现.希望此文能从需求、现状和解决方式的角度帮大家理解隔离级别. 隔离级别的产生 在串型执行的条件下,数据修改的顺序是固定的、可预期的结果,但是并发执行的情况下,数据的修改是不可预期的...

成华区15767572405: mysql中的乐观锁和悲观锁怎么用 -
謇钞奥贝: 关于mysql中的乐观锁和悲观锁面试的时候被问到的概率还是比较大的. mysql的悲观锁:其实理解起来非常简单,当数据被外界修改持保守态度,包括自身系统当前的其他事务,以及来自外部系统的事务处理,因此,在整个数据处理过程中,...

成华区15767572405: mysql悲观锁和乐观锁的区别 -
謇钞奥贝: 悲观锁与乐观锁是两种常见的资源并发锁设计思路,也是并发编程中一个非常基础的概念.本文将对这两种常见的锁机制在数据库数据上的实现进行比较系统的介绍. 悲观锁(Pessimistic Lock) 悲观锁的特点是先获取锁,再进行业务操作,即...

成华区15767572405: mysql默认锁是悲观还是乐观 -
謇钞奥贝: 关闭命令为:set autocommit=0; 悲观锁可以使用select…for update实现,在执行的时候会锁定数据,虽然会锁定数据,但是不影响其他事务的普通查询使用.此处说普通查询就是平时我们用的:select * from table 语句.在我们使用悲观锁的时...

成华区15767572405: mysql怎么设置悲观锁 -
謇钞奥贝: 在mysql中可以使用select…for update实现悲观锁.这样那条数据就被我们锁定了,其它的事务必须等本次事务提交之后才能执行.从而保证数据不会被其他事务更改从而导致数据的异常.但是select…for update不会阻塞select的查询.需要注意的是mysql在采用InnoDB时,默认为行锁,且只有明确额指定主键,MySQL 才会执行行锁,锁住对应的那条数据,否则MySQL 将会执行表锁(将整个数据表单给锁住).

成华区15767572405: mysql 乐观锁怎么解决幻读 -
謇钞奥贝: mysql 乐观锁怎么解决幻读 由于事务的并发执行,带来以下一些著名的问题:(1)更新丢失(LostUpdate):当两个或多个事务选择同一行,然后基于最初选定的值更新该行时,由于每个事务都不知道其他事务的存在,就会发生丢失更新问题--...

成华区15767572405: mysql 非事务中的锁怎么处理 -
謇钞奥贝: 表级锁:开销小,加锁快;不会出现死锁;锁定粒度大,发生锁冲突的概率最高,并发度最低.l 行级锁:开销大,加锁慢;会出现死锁;锁定粒度最小,发生锁冲突的概率最低,并发度也最高.l 页面锁:开销和加锁时间界于表锁和行锁之间;...

成华区15767572405: mysql 表加读锁别的sql还能在操作该表吗 -
謇钞奥贝: 不能操作了, innodb四种级别的锁, 未提交读, 已提交读, 可重复读 和 可序列化, 不知道你说的是哪个 如果是限制读, 那就是是最高级别了, 其他操作都不行了.

成华区15767572405: mysql数据库中,我用lock锁表后提示错误.劳驾帮忙看一下 -
謇钞奥贝: 在 MySQL 中,如果你显式的执行锁定语句(LOCK Tables ...) 那么你必须一次锁定在解锁之前需要访问的所有表,而且,如果你以读锁定方式锁定的表,则不能对该表进行写操作,也就是说,你使用什么方式进行的锁定,就只能进行什么方式的操作 甚至如果你在 Query 语句中使用了别名,那么在之前的锁定中也必须使用别名

成华区15767572405: 如何给oracle数据库添加乐观锁 -
謇钞奥贝: 乐观锁一开始也说了,就是一开始假设不会造成数据冲突,在最后提交的时候再进行数据冲突检测.在乐观锁中,我们有3种 常用的做法来实现.[1]第一种就是在数据取得的时候把整个数据都copy到应用中,在进行提交的时候比对当前数据库中...

本站内容来自于网友发表,不代表本站立场,仅表示其个人看法,不对其真实性、正确性、有效性作任何的担保
相关事宜请发邮件给我们
© 星空见康网