美文网首页
数据库系列3-隔离性

数据库系列3-隔离性

作者: xgangzai | 来源:发表于2019-11-22 19:23 被阅读0次

    现在常规的应用系统中,每一个接口基本都需要执行多条更新SQL。这就要求多条SQL的更新要么全部生效,要么全部都不生效。这就是所谓的原子性,事务的四大特性之一。MySQL原生的存储引MyISAM是不支持事务的,因此大部分场景都需要用InnoDB存储引擎,其也是新版MySQL的默认存储引擎。

    事务之ACID特性

    Atomicity-原子性

    Consistency-一致性

    Isolation-隔离性

    Durability-持久性

    隔离级别是为了解决多个事务同时执行过程中,会出现的脏读,不可重复读和幻读问题

    脏读-Dirty Read

    读到了其他事务未提交的更新,当那个事务回滚后,这条更新就是脏数据了。

    不可重复读-Nonrepeatable Read

    针对同一条数据,第一次读的时候还未提交,第二次再读的时候,已经提交了,所以读到了。

    幻读-Phantom Read

    针对范围查询,第二次再读的时候,其他事务提交了一条更新,在这个范围内。对当前事务来说,

    第二次读的时候,比第一次读的时候多了一条数据。

    针对上面每种问题,数据库规范?定义了四种隔离级别

    READ_UNCOMMITED

    当前事务可以看到其他事务未提交的更新

    READ_COMMITED

    当前事务只能读到其他事务已提交的更新

    REPEATABLE_READ

    当前事务中任何时刻读取的数据都一致,即使其他事务的更新已经提交了

    SERIALIABLE

    事务串行

    各种隔离级别的实现方案,事务访问的数据都是以视图的逻辑结果为准。在REPEATABLE_READ隔离 级别下,这个视图是在事务启动时创建的,整个事务存在期间都用这个视图。在READ_COMMITED隔离级 别下,这个视图是在每个SQL语句开始执行的时候创建的。这里需要注意的是,READ_UNCOMMITED隔离级别下直接返回记录上的最新值,没有视图概念;而SERIALIABLE隔离级别下直接用加锁的方式来避 免并行访问。

    综上,为解决多事务并发问题,针对不同问题采用不同的解决方案

    1.MVVC-Multi Version Currency Control,利用undo log实现的视图逻辑结果,具体实现方案见[https://www.jianshu.com/p/f692d4f8a53e

    2.加锁,使事务串行执行

    问题:在具体实现中,两种方案是怎么配合使用的?

    试验,在实际试验不同事务隔离级的效果时,可以直接写SQL试验。

    开启事务的方式有以下两种

    begin;(或者 start transaction;)

    sql statement;

    commit; (回滚 rollback;)

    set autocommit=0

    开启了事务,怎么指定事务隔离级别。在MySQL中,事务隔离级别有

    全局级

    SELECT @@global.tx_isolation;

    会话级

    SELECT @@session.tx_isolation;

    所有的???

    SELECT @@tx_isolation;

    设置事务隔离的命令(不区分大小写)

    SET [SESSION | GLOBAL] TRANSACTION ISOLATION LEVEL {READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE}

    例如给当前连接上的事务设置隔离为读未提交

    set session transaction isolation level read uncommited

    如果不指定session 或者global,则设置对下一个事务生效。(不是太懂)

    试验一把,在一个连接中更新,但是不提交,在另一个连接中,设置事务隔离级别为read uncommited 然后查询,看是否能看到更新。果然能看到。

    有个问题,每一条SQL都是在事务下执行的。就算对于一个select语句来讲,也是在事务中的,因为当前的事务隔离级别决定了他能看到什么样的数据。

    所谓只读事务是什么概念??

    官方文档更能直至本质https://dev.mysql.com/doc/refman/5.7/en/innodb-autocommit-commit-rollback.html

    一直讲事务隔离级别,但是忽略了一个重要的概念,那就是autocommit

    根据上面的官方文档,所有的用户行为(我的理解是执行的任何DML语句)都是在事务里的(跟我上面的理解是一致的,哈哈哈)。如果开启了autocommit,每一个单独的SQL都会产生一个属于它自己的事务,所以SQL执行成功后(当错误后的处理策略再研究),MySQL就会自动执行commit操作。默认情况下,autocommit是开启的。所以我们执行完update insert等语句后,数据会及时持久化到磁盘。问题来了,如果关闭autocommit会有什么影响,这个配置是session级还是全局级的?

    第二个问题,通过试验(set autocommit =0;)得出结论,关闭autocommit只在当前session中生效,其他session不受影响。

    第一个问题,还是根据官方文档,如果关闭autocommit,一个session默认会开启事务,直到用户执行了commit或者rollback后,才会结束这个事务,并且再开启一个新事务。

    综上,要想将多个SQL明确放在一个事务中,便于统一提交或者回滚,有两种方式

    方式一、关闭autocommit,所有SQL执行完之后,再commit或者rollback。

    方式二、在执行第一条SQL前,执行begin或者start transaction,所有SQL执行完之后,再commit或者rollback。

    所以任何一条DML语句都是在事务中执行的,区别在于事务的范围(即包含了哪些SQL)以及事务的提交或者回滚执行的时刻。讲到这里,发现事务跟线程的概念相似,任何一段代码都是在某个线程中执行的,要么自己指定用哪个线程,要么就是系统提供的主线程。

    相关文章

      网友评论

          本文标题:数据库系列3-隔离性

          本文链接:https://www.haomeiwen.com/subject/tngqwctx.html