mysql的事物隔离级别

我们对于InnoDB这个数据存储引擎,他最大的特点是支持了事务,还记得吗,事务除了具有ACID的四大特性以外,

事务是不是还有个隔离级别,还记得是什么时候讲过,讲Spring的时候,Spring的事务控制有个Isolation,还记得吗

就是什么意思呢,如果你有多个并发的事务,同时操作一个数据,如果你对这个事务没有很好地隔离级别,那么就可以能

会出现脏读,虚读,对吧,不可重复读,丢失第一类更新,丢失第二类更新的现象,总而言之,这个数据是有问题的,所以说

在定义事务标准的时候,除了那四大原则以外,事务的特点已经把隔离级别递出来了,也就是说,你数据库产品,如果想要

支持事务,你应该支持这4种隔离级别,这样就可以解决常见的数据读取的问题,比如四大隔离级别有哪些来着,能回忆起来

几个,Read-uncommit,读未提交,既然有读未提交,就有读已提交,还有一个Read-Commit,还有一个叫Repeatable-Read,

最后一个是什么,Read-Seriable,序列化,其实在这四个隔离级别当中,Serializable是事务最安全的,为什么,我记得当时

还举了这么个例子,我又一张银行卡,恰巧公司这个时候给我开工资,然后我又拿这张卡去取钱,同时在这个时间点两个事务

操作同一个账户,就会有这样的问题,对吧,所以在定义事务特性的时候,就已经把隔离级别定义出来了,具备一种什么什么的

隔离级别,能够解决什么问题,那么我们刚才所说的4个隔离级别,其实就可以解决脏读,虚读,不可重复读的一系列问题,

只是级别的顺序影响了他的事务隔离级别的严谨性,比如最严谨的是谁啊,就是Serializable,哪有人说Serializable这么

严谨了,数据为什么不用一个Serializable就行了,没错,数据越严谨数据越安全,但是会严重的影响效率和性能,咱们在

讲数据库的时候,比如92标准下,这点相对于我们觉得比较高达上的ORACLE,其实ORACLE对于事物的隔离级别就支持两种,

一直叫做Serializable,一种叫做Repeatable-Read,剩余的读已提交,读未提交,ORACLE不支持,所以从这一点来看,

ORACLE的默认级别就是Repeatable-Read,而MYSQL的默认隔离级别是Read-Commit,其实你会发现,大多数的关系型的数据库的

默认隔离级别是都是Repeatable-Read,但是MYSQL默认的是读已提交,Read-Commit,能不能记住这四个隔离级别

事务的隔离级别:

1. read-committed : 读已提交 (是MSYQL的默认隔离级别)

2. read uncommitted : 读未提交

3. repeatable read (是Oracle的默认隔离级别)

4. Serializable 


就是四种隔离级别,然后repeatable read,是Oracle的默认隔离级别,读已提交是MSYQL的默认隔离级别,所以你要依赖数据库做

隔离级别,其实它控制的颗粒度是比较粗的,除非用数据库的Serializable,但是你把Serializable改了之后,就会降低其他的性能,

所以这个隔离级别真的去做,还不是去依赖数据库的隔离级别,而是依赖我们Spring的传播行为,Spring的事务隔离级别最好的是

他可以把隔离级别细化到方法上,也就是仅限于这样的一个方法,受这样的事务隔离级别,我们不是要配传播行为吗,required,

后面有一个Isolation,那个不就是配隔离级别的吗,所以用Spring来解决事务隔离级别方式更加细粒一些,那就借着这个机会

给大家说一下,如果有人问你MYSQL里面的隔离级别,说不出来,其实这块是可以说出来的,没有太大的问题,但是你要看每一个隔离

级别单独的解决什么样的问题,脏读,虚读,这些东西,那也不复杂,你到网上搜一遍,不过多介绍了