MySQL数据库事务与锁

MySQL事务

    事务的特性ACID,分别表示原子性(atomicity)、一致性(consistency)、隔离性(isolation)、和持久性(durability)。一个运行良好的事务处理系统,必须具备这些标准特性。

    1. 原子性(atomicity)
    一个事务必须被视为一个不可分割的最小工作单元,整个事务中所有操作要么全部提交成功,要么全部失败回滚,对于一个事务来讲,不可能只执行其中的一部分操作,这就是事务的原子性。

    2. 一致性(consistency)
    数据库总是从一个一致性的状态转换到另一个一致性的状态。

    3. 隔离性(isolation)
    通常来说,一个事务所做的修改在最终提交以前,对其他事务是不可见的。

    4. 持久性(durability)
     一旦事务提交,则其所做的修改就会永久的保存到数据库中。此时即使系统崩溃,修改的数据也不会丢失。

隔离级别

    隔离性其实比想象中的要复杂。在SQL标准中定义了四种隔离级别,每一种隔离级别都规定了一个事务中所做的修改,哪些在事务内或事务间是可见的,哪些是不可见的。较低级别的隔离通常可以执行更高的并发,系统开销也低。

READ UNCOMMITTED(未提交读)
    在 READ UNCOMMITTED 级别,事务中修改,即使没提交,对其他事务也都是可见的。事务可以读取未提交的数据,这也被称为脏读。这个级别会导致很多问题,从性能上来说 READ UNCOMMITTED 不会比其他的级别好太多,但却缺乏其他级别的很多好处,除非真的有非常必要的理由,在实际应用中一般很少使用。

READ COMMITTED(提交读)
    大多数数据库系统的默认隔离级别都是 READ COMMITTED (但MySQL不是)。READ COMMITTED满足前面提到的隔离性的简单定义:一个事务开始时,只能“看见”已经提交的事务所做的修改。换句话说,一个事务从开始直到提交之前,所做的任何修改对其他事务都是不可见的。这个级别有时候也叫做不可重复读(nonrepeatable read),因为两次执行同样的查询,可能会得到不一样的结果。

REPEATABLEB READ(可重复度)
    REPEATABLEB READ解决了脏读的问题。该级别保证了在同一个事务中多次读取同样记录的结果是一致的。但是理论上,可重复读隔离级别还是无法解决另外一个幻读(Phantom Read)的问题。所谓幻读,指的是当某个事务在读群某个范围内的纪录时,另外一个事务又在该范围内插入了新的记录,当之前的事务再次读取该范围的纪录时,会产生幻行(Phantom Row)。InnoDB和XtraDB存储引擎通过多版本并发控制器(MVCC,Multiversion Concurrency Control)解决了幻读的问题。可重复读是MySQL的默认事务隔离级别。

SERIALIZABLE(可串行化)
    SERIALIZABLE 是最高的隔离级别。它通过强制事务串行执行,避免了前面说的幻读的问题。加单来说,SERIALIZABLE会在读取的每一行数据上都加锁,所以可能导致大量的超时和锁争用问题。实际应用中也很少会用到这个隔离级别,只有在非常需要确保数据的一致性而且可以接受没有并发的情况下,才考虑采用该级别。

InnoDB采用MVCC来支持高并发,并实现了四个隔离级别。其默认级别是 REPEATABLEB READ(可重复度),并且通过间隙锁(next-key locking)策略防止幻读的出现。间隙锁使得InnoDB不仅仅锁定查询涉及的行,还会对索引中的间隙进行锁定,以防止幻影行的插入。

ANSI SQL隔离级别

隔离级别脏读可能性不可重复度可能性幻读可能性加锁读
READ UNCOMMITTEDYESYESYESNO
READ COMMITTEDNOYESYESNO
REPEATABLEB READNOYESYESNO
SERIALIZABLENONONOYES

下面测试一下MySQL在 REPEATABLEB READ 隔离级别下能否避免幻读(前提是InnoDB引擎
在customer表做测试
1ba2614f41aee88d96d44e9d3a8744a8f28.jpg

在A事务开启事务,查询年龄在12~16的结果
38704b70ab71f28ef663662f810d6a24d37.jpg
结果如下:此时A事务并没有提交
b454e4f5b8555d0943e9294b7170ad5e41d.jpg

B事务,在customer表中插入一条age = 14的数据
2ed21b1eead16ded59fd11f22c2b60a8f5c.jpg
select语句结果为
6978fd873738c3a84d15470c5027bd0b4fc.jpg
此时B事务未提交,customer表依然是
292dab5464a93ab9de9b85044467824ab1a.jpg
说明 REPEATABLEB READ 隔离级别可以避免脏读。B事务commit之后xustomer表为
71c514b5dda7815bd241324e8fcb04734ac.jpg
此时A事务再执行select语句结果依然为
b615a29411af12819753e367a451cc368ad.jpg
说明MySQL数据库在 REPEATABLEB READ 隔离级别下可以避免幻读(InnoDB引擎)。commit后再次执行select结果为
6978fd873738c3a84d15470c5027bd0b4fc.jpg
现在就恢复了B事务的操作。

结论:MySQL数据库在 REPEATABLEB READ 隔离级别下可以避免幻读(InnoDB引擎)。数据库的事务是为了保证数据的安全,事务特性中的一致性相对重要一些。

锁是为了保证事务的隔离性。锁是基于索引实现的。

读锁和写锁
    共享锁(shared lock)和排他锁(exclusive lock)也叫读锁(read lock)和写锁(write lock)
读锁是共享的,互相不阻塞的,多个客户在同一时刻可以同时读取同一个资源,而互不干扰。读锁对写锁阻塞。写锁则是排他的,也就是说一个写锁会阻塞其他的读锁和写锁,这是出于安全策略的考虑,只有这样,才能确保在给定的时间里,只有一个用户能执行写入,并防止其他用户读取正在写入的统一资源。

    写锁比读锁有更高的优先级,一个写锁的请求可能会被插入到读写队列的前面。

行锁和表锁
    表锁是MySQL最基本的锁策略,并且是开销最小的策略。会锁定整张表。没有命中索引的操作会锁表
    行锁可以最大程度的支持并发处理,同时带来了最大的锁开销 InnoDB 和 XtraDb 引擎实现了行级锁。会锁住某一行或者某几行,表中其他行的数据可以进行读写操作。命中索引,则会将某一行或者某几行加锁。

死锁
    两个或者多个事务在同一资源上相互占用,并请求锁定对方占用的资源,从而导致恶性循环的现象。InnoDB处理死锁的方式是,将持有最少行级排他锁的事物进行回滚。锁的行为和顺序是和存储引擎相关的。以同样的顺序执行语句,有些存储引擎会产生死锁,有些则不会。

悲观锁和乐观锁
    悲观锁,假设丢失更新一定存在;sql后面加上for update(排他锁)。
   
乐观锁,假设丢失更新不一定发生。update时候存在版本,更新时候按版本号进行更新。

记录锁、间隙锁和临键锁
    记录锁,会锁住某一行数据,条件命中主键索引。where id = ?;如果在主键上加范围查询(where id > ?),记录锁会退化成间隙锁,锁住不符合条件的最近的值开始的所有。
    间隙锁,会锁住一个范围,条件命中非主键、非唯一索引,只有在重复读的隔离界别下存在。如果是(where age > ?) ,锁住不符合条件的最近的值开始的所有(前闭后开),也就是锁住索引中的间隙。
    临键锁,InnoDB默认行级锁,条件命中非主键、非唯一索引,会锁住一个范围,查出来的范围以及相邻的下一个区间都锁住。where age = ?则该值两侧的值的范围内被锁住(前闭后开)。

意向共享锁和意向排他锁
    意向共享锁,当一个事务试图对整个表进行加共享锁之前,首先需要获得这个表的意向共享锁。
    意向排他锁,当一个事务试图对整个表进行加排它锁之前,首先需要获得这个表的意向排它锁。
    

转载于:https://my.oschina.net/u/4149810/blog/3077630

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值