MySQL事务与锁

一、事务与事务特性

在关系型数据库内,事务是由一个SQL或一组SQL语句组成的逻辑处理单元。也就是说事务就相当于一个盛放SQL的容器,事务中的SQL要么全部执行成功,要么所有已经修改的操作都回滚到原来的操作,即一条SQL也不能执行成功。

事务的四大特性(ACID):

原子性:

事务作为一个整体被执行,包含在其中的对数据库的操作要么全部被执行,要么都不执行,当在执行过程中出现错误,就会回滚到事务开始前的状态。

一致性:

事务的执行结果必须是从一个一致性状态向另一个一致性状态的变更。比如,A和B两人共有100元,那么不管A转钱给B,或者B转钱给A,A+B的金额永远是100。

隔离性:

多个事务并发执行时,一个事务的执行不应影响其他事务的执行。

持久性:

一个事务一旦提交,他对数据库的修改应该永久保存在数据库中,任何事务或故障都不应导致数据丢失。

二、MySQL事务的3种运行模式

隐式==自动

显式==手动

自动提交事务(隐式开启、隐式提交)

MySQL默认的事务运行模式,在每条SQL执行完毕之后自动commit提交。

隐式事务(隐式开启、显式提交)

由于在MySQL中是默认每条SQL都开启了事务的,并且每条SQL执行完毕之后都会自动提交,这样的话就只需要将自动提交关闭就可以了。

# 零时关闭 (关闭当前数据库连接在从新连接就恢复了) set autocommit = 0; # 永久关闭 (修改配置文件my.cnf) autocommit = 0

显示事务(显示开启、显示提交)

这就是我们手动开启事务,将SQL语句放在我们手动开启的事务中。

start transaction; SQL语句; commit; # 提交、或rollback回滚

当使用了commit或者rollback后事务就结束了,在此进入需要从新开始。

三、数据库读现象

在高并发场景下,并发的多个事务去操作同一份数据,而产生的一些奇怪的现象,是数据不安全的一种体现。

脏读

一个事务在对一条数据进行了修改,在这个事务还没有提交时,另一个事务也读取了这条数据,如果没有控制,那么第二个事务读到的就是一条脏数据,如果第二个事务还需要对这条数据进行操作,那么这两个事务之间就存在依赖关系,这就叫脏读。总结一句话就是事务A读取到了事务B已经修改了但未提交的数据。

不可重复读

同一个事务在读取某个数据后,隔一段时间再次读取该条数据,在这中间该数据被另一个事务给修改,导致两次读取的数据不一致。

幻读

幻读就是不可重复读的一种现象,同一个事务使用相同的查询条件读取以前检索的数据,却查询到了其他事务插入的符合条件的数据,这种现象叫做幻读。也就是说事务A读取到了事务B提交的新增数据。

四、锁机制

锁是一种保障数据安全的机制,也就是协调多个进程或线程并发访问某一资源的机制。

以互斥锁为例,让多个并发的任务同一时间只能有一个可以运行,牺牲了效率换来了数据安全。

锁的优缺点:

优点:保障并发场景下数据的安全。

缺点:降低了效率。

所以在使用锁的时候应该尽可能的缩小锁的范围,也就是锁住的数据越小越好,并发能力越高。

锁的分类:

按照粒度分类:行级锁、表级锁、页级锁。

按照级别分类:共享锁、排他锁。

按照使用方式分类:乐观锁(我在改数据的时候没有人在跟我修改同一份数据,也可以说其实它本身并不是一种锁,因为它是程序角度的一种写程序的套路,本质来说并没有加任何锁)、悲观锁(在我的事务里面,我在改数据的时候我总认为一定有人在跟我抢,悲观锁通常使用数据自带锁机制实现的)

行级锁:

行级锁它分为共享锁,排他锁,是MySQL中粒度最细的一种锁,所以它的并发能力也是最高的。

对于insert、update、delete语句、innodb会自动给涉及的数据加锁,而且是排他锁;

对于普通的select语句,innodb不会加任何锁,需要手动自己加,可以加两种类型的锁;

--共享锁(s):能同时加到锁和抢到锁的是多个,保障读的一致性 select * from 表名 where ... lock in share mode; --排他锁(x):同一时间只能有一个能抢到,保障写数据的安全 select * from 表名 where ... for update;

锁的使用:例如

1、事务A对id=3的行加了互斥锁后,其他事务对id=3的行不能加任何锁(写不行,但是可以读)

2、事务A对id=3的行加了共享锁后,其他事务对id=3的行只能加共享锁,或者不加锁(写不行,但可以读)

表级锁:

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/zzfxzp.html