二、Mysql事务(必会知识点)

Small_white_wall

已于 2022-07-06 17:36:07 修改

阅读量265

点赞数

分类专栏： Mysql 文章标签： mysql 数据库 java

于 2022-07-02 17:48:11 首次发布

本文链接：https://blog.csdn.net/Small_white_528/article/details/125573789

版权

Mysql 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

1.1 什么是事务?

事务可以理解成是一种约束，假如你要执行三条sql语句，这三条语句全部执行成功才可以达到你的目的，但是此时其中一条sql失败了或者因为某些其他原因导致没有执行，那么最终的执行结果就不是你原本想要的结果，所以我们就需要事务来约束捆绑这三条语句，要么三条sql都执行成功，要么三条sql都执行失败，这就是事务。

如果你没理解，那换个方式说。假如你去吃饭，你需要先掏钱、拿筷子、拿米饭(相当于三条sql语句)你才可以正常进行吃饭动作，但是如果此时没有米饭了(其中一条执行失败)，那么你怎么去吃饭呢? 这时是不是就和你原本想要的吃饭动作不一样了? PS(你总不能吃筷子吧...)，然后你去找店家把钱要了回来(相当于第一条sql回滚)，把米饭放回原位(相当于第二条sql回滚)，所以你干脆就不吃了，要么钱，筷子，米饭都有你进行吃饭动作，要么你不吃走人，这就叫事务，这样是不是可以容易帮助你理解什么是事务了?

1.2 事务的四大特性

上面我们明白了什么是事务也认识到了事务的作用，但是光知道什么是事务是远远不够的，你可以想象一下，就按我们上边举得例子来讲，你去吃饭的时候发现没有米饭了，你这时候要找店家退钱对不对，但是！！！店家这个时候跑了，是的，你没听错，带着你的钱跑了！(相当于系统崩溃)这时候怎么办，你饭也没吃，钱也没了。。。

1.2.1 原子性

一个事务必须被看作是一个整体，或者叫做工作单元，整个事务的操作要么全部成功，要么全部失败回滚。

1.2.3 一致性

数据库必须从一个一致性状态转换到另一个一致性状态。这句话有点不太好理解，我们还拿上边的例子举例，你去吃饭了对不对，但是注意，你为了防止TA逃跑，你不给TA钱，你发现筷子，米饭，都成功的拿到了(相当于其他的sql语句执行成功)，这时你才会把钱给他(相当于提交事务)。如果店家跑了(系统崩溃了)，这时你也没有损失，因为你的钱没有给他(相当于回滚事务)

1.2.3 隔离性

事务和事务之间是不可见的，也就是一个事务提交之前，其他事务是看不见这个这个事务的操作的。举个例子就是你吃饭的时候拿走了最后的一双筷子，但是你还没有付钱(没有提交事务），这时进来了另外一个顾客，他是不知道你把最后一双筷子拿走了的。PS:这里你是不是有了一些疑问了?没关系，我们后面说，现在只需要知道隔离性是什么就可以，如果这里你没有什么疑问，那么证明你还没有理解事务。。。

1.2.4 持久性

只要提交了事务，那么事务内的sql语句就会持久化到数据库中。这里有个一定要知道的知识点，这里的持久化不是百分百会持久化到数据库成功的，也就是说即使你的事务提交了，也不一定会保存到数据库中，说个场景，你的事务提交了，在持久化数据库的时候，系统崩了，这批数据依旧会丢失

1.2.5 四大特性总结

这四大特性，专业名词叫ACID，分别代表四个特性，A(原子性atomicity)， C(一致性consistency)，I(隔离性isllation)，D(持久性durability)。

四大特性就像锁粒度(不知道锁粒度的看我第一章文章http://t.csdn.cn/C77sZ)一样，会额外的增加系统消耗，一个实现了ACID的数据库系统，要给TA更高更优的cpu，更大的内存空间和磁盘容量，而在我们的应用业务系统中要实现这一套ACID也很困难，所幸我们Mysql的存储引擎会自带一些特性(每个不同的存储引擎自身所携带的特性是不同的)，我们日常开发中可以根据实际的业务场景来选择合适的存储引擎来获取更好的系统性能，即使选用的存储引擎不持支事务，我们也可以自己来使用一些其他方式实现

1.3 隔离级别

隔离级别就是规定在一个事务中所做的修改，那些在事务内和事务间是可见的，那些是不可见的。较低级别的隔离性可以支持更高的并发，系统开销也会相应更低。

隔离级别同样也有四个

1.3.1 未提交读(READ UNCOMMITTED)

在这个级别中，即使一个事务没有提交，其他事务也是可以看见这个事务做出的修改的。事务可以读取到其他事务没有提交的数据，被称为脏读。看到这里相比你也意识到TA的问题了，会导致数据混乱，而且性能也没有比其他隔离级别好太多。在日常开发中，这个级别一般不会用到

1.3.2 提交读(READ COMMITTEN)

大多数数据库采用的默认隔离级别都是提交读，注意哈，我们的Mysql不是(那些数据库默认是这个级别大家可以自己查资料)，这个隔离级别满足我们前面说的隔离性，一个事务只能看到其他事务提交后的数据，事务间的数据不会共享，被称为不可重复读。因为如果你执行两次相同的操作，读取到数据可能是不一样的（因为在你执行两次的时候有可能其他事务提交了修改呀，所以你第二次读取到的数据有可能是其他事务提交后的数据）

1.3.3 可重复读(REPEATABLE READ)

这个隔离级别解决了脏读的问题，保证在同一个事务中，多次读取数据时一致的，但是理论中，无法解决另一个问题，就是幻读。什么是幻读，幻读就是假如有一个事务A正在查询数据，但是这个时候另一个事务B在这个数据范围内插入了一条新的数据，当A进行第二次数据查询时就会查到这条新的数据，总结来讲就是同一个事务中后一次查询会查到前一次查询没有查到的数据，在InnonDB和XtraDb存储引擎中通过多版本并发控制解决了幻读的问题(后面说)。注意，Mysql默认隔离级别就是可重复读

1.3.4 可串行化(SERIALIZABLE)

可串行话时隔离级别最高的，TA强制事务串行化执行，避免了幻读问题。简单说就是TA会在读取的每一行数据上强制加锁，但是同时也会导致大量的超时和抢锁的情况，所以我们日常开发很少会用到这个隔离级别，除非时那种必须确保数据一致性而且可以接受没有并发的情况下。

1.4 死锁

死锁就是指两个或多个事务在同一资源上相互占用，并请求锁定对方占用的资源，导致循环请求的情况。多个事务以不同的顺序锁定资源或者同时锁定同一个资源时就会发生死锁。举个例子，现在有两个人A和B(事务A和事务B)，同时去食堂打饭，A拿到了勺子，B拿到了筷子，这时A用完了勺子需要用筷子， B用完了筷子要用勺子，但是A要用完筷子才可以归还勺子，B要用完勺子才可以归还筷子，这时A和B两个都在等待对方归还各自需要的东西，就会发生一直等待下去的情况，这就叫死锁。

为了解决这个问题，数据库系统实现了各种死锁检测和死锁超时机制，越复杂的系统越能检测到死锁的循环依赖，并返回一个错误信息提示。还有一个解决办法就是设定锁等待时间，当等待锁时间超过设定的时间就放弃锁请求，这种方式一般不太会用到，因为如果你放弃了意味着你本次操作就失败了，对于用户来讲不太友好。InnonDB(存储引擎)的解决方法是将持有最少行级排他锁(不清楚排他锁概念的看第一章文章http://t.csdn.cn/C77sZ))的事务进行回滚。这种处理方式也叫做死锁回滚算法。

锁的行为和顺序是和存储引擎有关系的，已同样的顺序执行语句，有些存储引擎会死锁，有些则不会。死锁产生的原因有些是因为真正的数据冲突，就像前边举得例子一样，有些则是因为存储引擎的实现方式引起的。

死锁产生后，只有部分或者是整个事务回滚才可以打破死锁，对于业务性系统而言，这种情况是无法避免的，所以我们可以在程序中进行处理，大部分情况下回滚重新执行即可。

1.5 事务日志

什么是事务日志? 事务日志可以理解为一种记录事务操作的机制，也就是说你的事务提交或者是回滚，都会记录下来存储在磁盘中。

事务日志有啥好处? 为啥要用事务日志? 前面我们说过，在我们执行sql语句时，是会有事务产生的，在事务提交或者回滚的时候，是会占用IO来进行磁盘操作的，如果有多个事务意味着同时会有多个零零散散的磁盘IO操作。这个时候就体现出事务日志的好处了，存储引擎修改数据的时候修改内存拷贝数据，事务日志是占用磁盘上一块固定区域的顺序IO，这样每个事务提交或回滚都会按照顺序记录在事务日志中，之后在由服务器来执行事务日志中的记录更新数据。