mysql 锁机制(一)
前言
介绍mysql 锁的机制。
正文
锁类型
读锁,是一种共享锁,s锁,允许一个事务是读取一行,阻止其他事务获取相同的数据集的排他锁。
注:排它锁的意思就是说只能加相同的锁,不能加不同的锁,比如都加共享锁,也就是说大家可以都读取。
假如事务A对数据项Z进行s锁,那么事务B只能添加s锁,而不能添加互斥锁,也就是X锁。这保证了,其他事务可以读取Z,
但是在A的S锁释放之前,是不能进行任何修改的。
写锁,是互斥锁的一种,x锁。允许获取排它锁的事务更新数据,阻止其他事务取得相同的数据及共享读锁和排它写锁。
也就是说,加入事务A对数据项Z加了写锁,那么会产生一个效果,那就是其他事务就不能对该数据加任何锁了,这个时候
A可以对数据项Z进行读取和修改。
锁对象
这里介绍锁对象。
表锁:一次性对一张表整体加锁,是mysql中最大颗粒度的锁定机制。
MylSAM 存储引擎就是使用表锁,开销小、实现逻辑非常简单,带来的系统负面影响小,加锁和释放锁快,无死锁,但是锁范围大,容易发生锁冲突,并发最低。
行锁:一次性对一条数据加锁,锁定对象的颗粒度小。也就是我们常用的innodb可以用到行锁,开销大,加锁慢,容易出现死锁;锁的范围较小,不易发生锁冲突,并发高。
页面锁:锁定颗粒介于表锁和行锁之间;开销和加锁时间介于表锁和行锁之间。会出现死锁;并发度一般。
具体使用哪种引擎,哪种级别的锁,还是要看业务的,一般来说需要高并发的一般都是用innodb。
innodb
事务
为什么提及到这个innodb东西呢?是因为,俺只用到这东西,其他只是在理解层面上。
innodb 在锁的概念上两个特征,一个是支持事务,第二个就是行锁。
为什么说出这两个特征,前面提及过一个问题,就是说行锁有几个问题,开销发,加锁慢,容易出现死锁。
这里再次介绍事务的ACID。
原子性(actomicity),事务是一个操作单元对数据修改要不全部执行,要不就是全不执行。
一致性(Consistent),在事务开始和完成的时候,数据必须保持一致状态。
隔离性(lsolation),数据库系统提供一定的隔离机制,保证事务在不受外部并发影响的独立环境执行。
持久性(durable),事务完成之后,他对于数据的修改是永久性的,即使出现系统故障也能够保持。
同样的,因为事务需要保持着这几种特性,才能说是一个合格的事务。
因为事务的并发,然后又是行锁,那么就会产生一系列并发问题。
假设在不采用锁措施的情况下:
1.脏读:一个事务正在对一条数据做修改,在这个事务提交前。这时候另外一个事务也用来读取该条数据,这个时候就是读取了未提交的数据了。
2.不可重复读:一个事务在读取某些数据已经发生了改变,或某些记录已经被删除了。其实就是两次读取不一致。
是这样的,事务可以看成一系列事件的执行,比如说事件A进行读取数据Z,然后其他事务对数据Z进行写操作,那么A后面一个事件B也是读取操作,这个时候B读取到的数据和A读取到的数据不一致。
所以这个就叫做不可重复读,其实就是事务的隔离性被破坏。
幻读:一个事务两次的查询条件重新读取以前的数据已经发生数量的改变。比如说同一个事务T, A事件 读取到的数据是10条,然后事务B进行了增加一条,那么问题来了,事务B执行相同条件的查询的时候就出现了问题。
更新丢失:这个很好理解了,如果理解了脏读的话,这个就更好理解了,是这样子的,如果两个事务,同时对一条数据进行修改,然后分不同时候提交,那么肯定有一个是没有保存。
事务隔离
通过事务的隔离,来解决一些问题,但是呢,也要权衡利弊,为啥这么说呢?加锁肯定降低性能的。
1.读未提交:
就是不加锁,上面的问题就是因为不加锁导致的,所以说,you know。
2.读已提交
就是说事务只能读取到其他事务提交后的东西,写锁。
这个东西可以解决脏读,为什么这么说呢?因为脏读不就是读取没有提交的数据。
但是不可重复读还是会发生,是这样的,不可重复读是因为一个事务的事件中间穿插了其他事务的写事件。
3.可重复读
事务不会读到其他事务对已有数据的修改,及时其他事务已提交,也就是说,事务开始时读到的已有数据是什么,在事务提交前的任意时刻,这些数据的值都是一样的。
幻读问题依然存在。
4.串行化
这个不并发自然不产生问题。
结
该节为简单介绍,后续为悲观和乐观锁。