• Mysql InnoDB引擎的读锁


    Mysql官方手册读锁说明

    如果,在一个相同的事务中,你查询数据,然后插入/更新与此数据相关的数据,那个通常的SELECT语句不会给我们足够的保护.因为在我们当前事务的SELECT和UPDATE之间的时间段内,其他的事务可能会更新/删除我们刚刚读取到的行.而我们根本不会察觉.

    InnoDB支持两种类型的读锁,可以给我们提供足够的安全.

    1.SELECT ... LOCK IN SHARE MODE 

    这是共享锁,在读取的任何数据上设定一个共享模式的锁.其他事务可以读取这些数据.但是不能修改这些数据,除非我们设定锁的事务提交了.如果我们查询的数据正被其他事务修改,而且这些事务还没有提交,那么我们的查询会一直等待,直到这些事务提交,然后我们的查询就使用这些最新的数据.

    注意:要想正确使用SELECT ... FOR UPDATE/SELECT ... LOCK IN SHARE MODE,必须关闭自动提交事务(set autocommit = 0),或者手动开启一个事务(begin/start transaction),如果不开启事务,那些查询到的数据不会被加锁

    2.SELECT ..... FOR UPDATE;

    这是独占锁,会阻塞其他尝试修改的事务、使用SELECT....LOCK IN SHARE MODE的事务和一些事务隔离级别的事务(如FOR UPDATE)。

    举例SELECT...FOR UPDATE,此方法要读取最新的结果

    第一种情况,事务1开启事务并查询某条记录接着然后执行随后的动作, 

    事务1开启事务并查询一条记录

    注意事务1并没有提交,此时事务2企图UPDATE此条记录

    然而由于事务1还没有提交,事务2的UPDATE要等待,此刻用事务1再次查询此条记录,看记录有没有被改

    上图可以发现,password并没有变

    然后,事务1等了一会儿,终于提交了

    这时候去看事务2,由于事务1commit后释放了锁,事务2就得到了锁,立刻返回了结果:

    然后我再查询此条记录,发现终于更新为333了

    在业务场景中,如果两个事务都使用lock in share mode,然后进行更新操作。如两个事务都获取了共享锁,在释放锁(commit或者roll back)之前都去执行update,由于update操作需要等待对方释放锁,就造成了死锁(deadlock),这是业务不允许的,所以一般使用FOR UPDATE让事务获取独占锁,完成事务后,才允许其他事务获取锁。

     注意:

    1.如果开启了事务1,在事务1的过程中,事务1执行SELECT(尚未提交),事务2修改了数据并提交,此时,就算事务1再次执行SELECT,事务1也不会查到事务2所做的改动。除非重新开启事务。

    2.加共享/独占锁的前提是:其他事务已经释放了独占锁

    3. 关于 AUTOCOMMIT

    因为涉及到事务,所以InnoDB才有自动提交这一说。虽然Myisam引擎中使用SET AUTOCOMMIT不会报错,但是由于没有事务功能,使用这条语句无效,没意义。

    在InnoDB中,所有的用户行为都是在事务中发生,如果自动提交允许,每个SQL语句在它自己上形成一个单独的事务,mysql总是带着允许自动提交来开始一个新的连接.

    但是,如果自动提交模式被用"SET AUTOCOMMIT = 0"关闭了,那么我们可以认为一个用户总是有一个事务在开着.

    "COMMIT"或"ROLLBACK"语句结束当前事务并且开始新的事务,一个"COMMIT"语句意味着在当前事务中做的改变被生成永久的,并变成其他用户可见的.而一个"ROLLBACK"则是撤销所有当前事务做的修改.

  • 相关阅读:
    Git 修改已提交的commit注释
    设置git bash中显示行号等
    JS 获取字符串长度
    泛型接口
    约束
    泛型方法
    泛型
    重载运算符
    自定义转换
    装箱和拆箱
  • 原文地址:https://www.cnblogs.com/ch459742906/p/6070078.html
Copyright © 2020-2023  润新知