事物隔离级别

事务的几大特性:

  • 原子性(Atomicity );

  • 一致性( Consistency );

  • 隔离性或独立性( Isolation);

  • 持久性(Durabilily)。

简称就是ACID。本文主要介绍隔离性的实现有哪些级别,和这些级别的具体讲解。

未授权读取

也称为读未提交(Read Uncommitted):允许脏读取,但不允许更新丢失。如果一个事务已经开始写数据,则另外一个事务则不允许同时进行写操作,但允许其他事务读此行数据。该隔离级别可以通过“排他写锁”实现。

授权读取

也称为读提交(Read Committed):允许不可重复读取,但不允许脏读取。这可以通过“瞬间共享读锁”和“排他写锁”实现。读取数据的事务允许其他事务继续访问该行数据,但是未提交的写事务将会禁止其他事务访问该行。

可重复读取(Repeatable Read)

可重复读取(Repeatable Read):禁止不可重复读取和脏读取,但是有时可能出现幻影数据。这可以通过“共享读锁”和“排他写锁”实现。读取数据的事务将会禁止写事务(但允许读事务),写事务则禁止任何其他事务。

序列化(Serializable)

序列化(Serializable):提供严格的事务隔离。它要求事务序列化执行,事务只能一个接着一个地执行,但不能并发执行。如果仅仅通过“行级锁”是无法实现事务序列化的,必须通过其他机制保证新插入的数据不会被刚执行查询操作的事务访问到。

隔离级别越高,越能保证数据的完整性和一致性,但是对并发性能的影响也越大。对于多数应用程序,可以优先考虑把数据库系统的隔离级别设为Read Committed。它能够避免脏读取,而且具有较好的并发性能。尽管它会导致不可重复读、虚读和第二类丢失更新这些并发问题,在可能出现这类问题的个别场合,可以由应用程序采用悲观锁乐观锁来控制。

3. 脏读、不可重复读、幻影读

1 脏读:当事务1修改了一条记录,没有提交时,事务2读取了该记录;当事务1回滚了,那么事务2的记录就是一条不存在的记录;

2 不可重复读:当事务1读取了一条记录,未提交事务,事务2修改了该条记录并且提交事务;事务1又读取了该条记录,发现两条记录不一样;

3 幻影读:当事务1根据某种检索条件读取了若干条记录,未提交事务;而事务2又插入了一条记录,该记录也符合事务1的检索条件;那么当事务1在根据相同查询条件检索数据时候,出现了不一致的现象。

根据锁机制来避免上诉问题:

排他锁:数据加锁后,只有锁的拥有者可以对该数据进行修改和读取,其他用户不能做任何操作,也不能加锁
共享锁:数据加锁后,所有用户都可以读取该对象,但是不能修改之,其他用户也可以加共享锁

处理以上隔离级别的问题,采用如下方是:
1 处理脏读:采用READ_COMMITTED,修改时加排他锁,直到事务提交后才释放,读取时加共享锁,读取完释放
事 务1读取数据时加上共享锁后(这样在事务1读取数据的过程中,其他事务就不会修改该数据),不允许任何事物操作该数据,只能读取,之后1如果有更新操作, 那么会转换为排他锁,其他事务更无权参与进来读写,这样就防止了脏读问题。但是当事务1读取数据过程中,有可能其他事务也读取了该数据,读取完毕后共享锁 释放,此时事务1修改数据,修改完毕提交事务,其他事务再次读取数据时候发现数据不一致,就会出现不可重复读问题,所以这样不能够避免不可重复读问题。
2 处理不可重复读:读采用RepeatableRead,取数据时加共享锁,写数据时加排他锁,都是事务提交才释放锁。读取时候不允许其他事物修改该数据,不管数据在事务过程中读取多少次,数据都是一致的,避免了不可重复读问题
3 处理幻影读问题:用Serializable,采用的是范围锁RangeS RangeS_S模式,锁定检索范围为只读,这样就避免了幻影读问题

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值