MySql事务

KleinBlueL

已于 2022-10-27 21:34:58 修改

阅读量886

点赞数 1

分类专栏： MySQL事务文章标签：数据库 mysql java

于 2022-08-11 16:47:32 首次发布

本文链接：https://blog.csdn.net/weixin_43080791/article/details/126288033

版权

MySQL事务专栏收录该内容

1 篇文章 0 订阅

订阅专栏

MySql事务

引入

原子性：
事务（transaction）中所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务执行过程发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。
一致性：
在事务开始前结束后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设规则，这包含资料的精确度、串联性以及后续数据库可以自发性地完成预定的工作。
隔离性：
数据库允许多个并发事务同时对其数据进行读写和修改，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括读未提交（Read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（Serializable）。
持久性：
事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

事务控制语句

BEGIN 或 START TRANSACTION 显式地开启一个事务；
COMMIT 也可以使用 COMMIT WORK，不过二者是等价的。COMMIT 会提交事务，并使已对数据库进行的所有修改成为永久性的；
ROLLBACK 也可以使用 ROLLBACK WORK，不过二者是等价的。回滚会结束用户的事务，并撤销正在进行的所有未提交的修改；
SAVEPOINT identifier，SAVEPOINT 允许在事务中创建一个保存点，一个事务中可以有多个 SAVEPOINT；
RELEASE SAVEPOINT identifier 删除一个事务的保存点，当没有指定的保存点时，执行该语句会抛出一个异常；
ROLLBACK TO identifier 把事务回滚到标记点；
SET TRANSACTION 用来设置事务的隔离级别。InnoDB 存储引擎提供事务的隔离级别有READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ 和 SERIALIZABLE。

MYSQL 事务处理主要有两种方法：
1、用 BEGIN, ROLLBACK, COMMIT来实现
BEGIN 开始一个事务
ROLLBACK 事务回滚
COMMIT 事务确认
2、直接用 SET 来改变 MySQL 的自动提交模式:
SET AUTOCOMMIT=0 禁止自动提交
SET AUTOCOMMIT=1 开启自动提交

保存点:
例如转账过程中张三给李四转账
张三完成扣钱后李四加钱的过程出现了错误此时rollback会直接回滚到事务开始的状态加上保存点后可以选择回滚到保存点的位置

事务隔离级别

READ UNCOMMITTED(读未提交)
解决了更新丢失问题，但还是可能会出现脏读
READ COMMITTED(读已提交)
解决了更新丢失和脏读问题
REPEATABLE READ (可重复度)
解决了更新丢失、脏读、不可重复读问题但是还会出现幻读
SERIALIZABLE(串行化)
解决了更新丢失、脏读、不可重复读、幻读(虚读)问题

更新丢失
两个事务在并发同时进行更新，后一个事务的更新覆盖了前一个事务更新,数据没有保证一致性导致的。
两类更新丢失情况

第一类回滚丢失。
A事务撤销时，把已经提交的B事务的更新数据覆盖了。
标准定义的所有隔离界别都不允许第一类丢失更新发生。

第二类更新丢失(覆盖丢失/两次更新问题)。
A事务覆盖B事务已经提交的数据，造成B事务所做操作丢失
第二类丢失更新，实际上和不可重复读是同一种问题。

脏读:
事务A读取了被事务B修改但是还未提交的数据
这样B事务回滚会导致A事务读取无效数据------也就是脏读(读写改操作)

幻读
事务A 按照一定条件进行数据读取，期间事务B 插入了相同搜索条件的新数据，事务A再次按照原先条件进行读取时，发现了事务B 新插入的数据称为幻读(如果事务A 按一定条件搜索，期间事务B 删除了符合条件的某一条数据，导致事务A 再次读取时数据少了一条。这种情况归为 不可重复读)

不可重复读:
A事务中,多次读取数据Data,在A事务还未结束时,B事务对Data进行了修改,提交后,A在B事务修改后获取的Data与修改前的数据不一致

当前读
像 select lock in share mode (共享锁), select for update; update; insert; delete (排他锁)这些操作都是一种当前读，为什么叫当前读？就是它读取的是记录的最新版本，读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁

快照读
像不加锁的 select 操作就是快照读，即不加锁的非阻塞读；快照读的前提是隔离级别不是串行级别，串行级别下的快照读会退化成当前读；之所以出现快照读的情况，是基于提高并发性能的考虑，快照读的实现是基于多版本并发控制，即 MVCC ,可以认为 MVCC 是行锁的一个变种，但它在很多情况下，避免了加锁操作，降低了开销；既然是基于多版本，即快照读可能读到的并不一定是数据的最新版本，而有可能是之前的历史版本

说白了 MVCC 就是为了实现读-写冲突不加锁，而这个读指的就是快照读, 而非当前读，当前读实际上是一种加锁的操作，是悲观锁的实现

小拓展

有些系统中第二类丢失更新可能就影响很大了，举个简单的例子：
财务系统加工资，若公司本次调薪决定给员工张三加1k人民币，财务部两名操作人员A和B，过程情况若是这样的：

1）A操作员在应用系统的页面上查询出张三的薪水信息，然后选择薪水记录进行修改，打开修改页面但A突然有事离开了，页面放在那没有做任何的提交。
2）这时候B操作员同样在应用中查询出张三的薪水信息，然后选择薪水记录进行修改，录入增加薪水额1000，然后提交了。
3）这时候A操作员回来了，在自己之前打开的薪水修改页面上也录入了增加薪水额1000，然后提交了。
其实上面例子操作员A和B只要一前一后做提交，悲剧就出来了。后台修改薪水的sql：update 工资表 set salary = salary + 增加薪水额 where staff_id = ‘员工ID’。这个过程走下来后结果是：张三开心了这次涨了2k，操作员A和B都郁闷了。

解决思路：
基本两种思路，一种是悲观锁，另外一种是乐观锁；
简单的说就是一种假定这样的问题是高概率的，最好一开始就锁住，免得更新老是失败；另外一种假定这样的问题是小概率的，最后一步做更新的时候再锁住，免得锁住时间太长影响其他人做有关操作。

解决方案1（悲观锁）
a.传统的悲观锁法（不推荐）：
以上面的例子来说明，在弹出修改工资的页面初始化时（这种情况下一般会去从数据库查询出来），在这个初始化查询中使用select …for update nowait，通过添加for update nowait语句，将这条记录锁住，避免其他用户更新，从而保证后续的更新是在正确的状态下更新的。然后在保持这个链接的状态下，在做更新提交。当然这个有个前提就是要保持链接，就是要对链接要占用较长时间，这个在现在web系统高并发高频率下显然是不现实的。

b.现在的悲观锁法（推荐优先使用）：
在修改工资这个页面做提交时先查询下，当然这个查询必须也要加锁（select …for update nowait），有人会说，在这里做个查询确认记录是否有改变不就行了吗，是的，是要做个确认，只是你不加for update就不能保证你在查询到更新提交这段时间里这条记录没有被其他会话更新过，所以这种方式也需要在查询时锁定记录，保证在这条记录没有变化的基础上再做更新，若有变化则提示告知用户。

解决方案2（乐观锁）
a.旧值条件（前镜像）法：
就是在sql更新时使用旧的状态值做条件，SQL大致如下 Update table set col1 = newcol1value, col2 = newcol2value…. where col1 = oldcol1value and col2 = oldcol2value….，在上面的例子中我们就可以把当前工资作为条件进行更新，如果这条记录已经被其他会话更新过，则本次更新了0行，这里我们应用系统一般会做个提示告知用户重新查询更新。这个取哪些旧值作为条件更新视具体系统实际情况而定。（这种方式有可能发生阻塞，如果应用其他地方使用悲观锁法长时间锁定了这条记录，则本次会话就需要等待，所以使用这种方式时最好统一使用乐观锁法。）

b.使用版本列法（推荐优先使用）：
其实这种方式是一个特殊化的前镜像法，就是不需要使用多个旧值做条件，只需要在表上加一个版本列，这一列可以是NUMBER或 DATE/TIMESTAMP列，加这列的作用就是用来记录这条数据的版本（在表设计时一般我们都会给每个表增加一些NUMBER型和DATE型的冗余字段，以便扩展使用，这些冗余字段完全可以作为版本列用），在应用程序中我们每次操作对版本列做维护即可。在更新时我们把上次版本作为条件进行更新。

c.使用校验和法（不推荐）

d.使用ORA_ROWSCN法（不推荐）

结论：
综上所述，我们对丢失更新问题建议采取上面的悲观锁b方法或乐观锁b方法（红字体已标注），其实这两种方式的本质都一样，都是在更新提交时做一次查询确认在更新提交，我个人觉得都是乐观的做法，区别在于悲观锁b方法是通过select…for
update方式，这个可能会导致其他会话的阻塞，而乐观锁b方法需要多一个版本列的维护。

其中小拓展引用https://blog.csdn.net/paopaopotter/article/details/79259686
当前读快照读引用
https://blog.csdn.net/SnailMann/article/details/94724197
学习笔记-22/08/11