浅谈数据库事务（database transaction）

在接触一个新的技术或者一个新的知识点的时候,个人认为认知了解阶段也就是第一印象真的很重要的:

了解该技术的概念和方向,概念是人类在认识过程中，从感性认识上升到理性认识，把所感知的事物的共同本质特点抽象出来，加以概括，看懂了概念往往能抓住本质,做到弯道超车;
思考该技术解决了什么问题或者难题,一个新技术的出现,往往是简化之前的代码亦或是提高提到代码的复用性亦或是一种新的思考方式;
回想像这一类的技术还有哪些,这样既能让你学过的的知识上升到知识体系,举一反三也是个记忆的好方法;
思考下这个技术是由哪些部分组成的;
思考下为什么会出现这个技术…懒ヽ(*。>Д<)o゜

讲到程序员的"懒惰",说一个题外话
知名的漫画家西乔，前段时间发了一组的漫画《为什么程序员们喜欢写脚本？》。讲的是一名程序员因为讨厌每次部署程序要运行多个命令，于是花了两倍时间写了个脚本执行。后来将脚本分享到开源网站上，帮助许多人快速完成部署工作的故事。
从某方面一说，懒惰是激发程序员开发新工具的源泉，越是懒惰的程序员，越喜欢用点小聪明（比如写个脚本），最大化的利用机器简化工作，程序的本质就是驱使机器去替人干活。懒惰的程序员，不愿意做繁复无聊的工作，所以会时刻思考用脚本代替自己，让自己处在一个高效节能的工作氛围中，以免浪费自己的体力、精力、时间。
程序员喜欢定脚本来偷懒，通常是因为：
1.现在需要重复2次，也许过几个月我还要重复2次，再过几个月还要重复2次
2.我可能一辈子就重复做2次这件事，但其他人是不是也要重复做2次
于是写完这个脚本之后，程序员们就会通过开源把它贡献出来，这些是对整个行业的积累。他们把自己完成的脚本贡献出来，经过各种汇总，抽象提升，制作出新的工具，给更多人用，接受更多人的贡献，最终让整个行业的技术水平大大提升了一步。
一个好的程序员应该是“懒惰的”，他懒到不愿意亲自重复做同样的事情3次，这才能在这个基础上创造出更好的工具。

所以应该这样说:程序员不是懒,是将一切磨难都变成前进的动力! ❀(๑╯◡╰๑)❀
逐渐脱离题目…以上是我借鉴了一个B站up加上自己的理解,这里也贴出阿婆猪的视频

定义

数据库事务（database transaction 简称：事务）是数据库管理系统执行过程中的一个逻辑单位，由一个有限的数据库操作序列构成。
定义解析成大白话,就是"要么全部成功,要么全部失败"“一秒回到解放前”
如果现在完整的业务，执行完这个业务需要n多个步骤，每一个步骤都可以与数据库进行增删改查,我们如果在不开启事务的情况下，直接执行业务，那么比如总共有五步，前两步成功之后，在执行第三步时出现了异常，导致后三步失败，但是前两步已经影响了数据库，这样在数据库中就会产生脏数据(错误数据).
在举一个例子:现在进行一个转账的简化业务

A现在需要转给B 500元人民币
查询数据库后判定A的账户余额大于500元,从A 的账户余额里将去500元
A已经完成了转出操作,接下来进行B的转入操作时,突然发生了系统错误,B的账户余额没有转入500元

看到这里我们就发现了问题了,而且这个问题我们是万万不可能让他出现的.事务就解决了这个问题,那他是怎么解决这个问题的呢?

首先我们对转账流程try…catch进行异常的捕获
在执行转账操作之前,修改事务为手动提交,即虽然查询了A账户余额并且进行了转出操作不进行数据提交conn.setAutoCommit(false);
然后,继续操作B账户余额的转入操作,确定整个流程完整无误后,手动进行数据提交conn.Commit();
如果期间的任何一步出现了异常导致流程没有完整的进行,捕获到异常后执行conn.roolback();回滚一切操作

就是将转账过程中的两次修改的sql操作，放入一个事务中，保证其全部成功、全部失败。

事务的四大特征

ACID四个特性

⑴ 原子性（Atomicity）
原子性是指事务包含的所有操作要么全部成功，要么全部失败回滚，因此事务的操作如果成功就必须要完全应用到数据库，如果操作失败则不能对数据库有任何影响。
⑵ 一致性（Consistency）
一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态。
拿转账来说，假设用户A和用户B两者的钱加起来一共是5000，那么不管A和B之间如何转账，转几次账，事务结束后两个用户的钱相加起来应该还得是5000，这就是事务的一致性。
⑶ 隔离性（Isolation）
隔离性是当多个用户并发访问数据库时，比如操作同一张表时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离。
即要达到这么一种效果：对于任意两个并发的事务T1和T2，在事务T1看来，T2要么在T1开始之前就已经结束，要么在T1结束之后才开始，这样每个事务都感觉不到有其他事务在并发地执行。
⑷ 持久性（Durability）
持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。
例如我们在使用JDBC操作数据库时，在提交事务方法后，提示用户事务操作完成，当我们程序执行完成直到看到提示后，就可以认定事务以及正确提交，即使这时候数据库出现了问题，也必须要将我们的事务完全执行完成，否则就会造成我们看到提示事务处理完毕，但是数据库因为故障而没有执行事务的重大错误。

未完待续

事务远远没有上面提到的那么浅显,其实事务还有四个隔离级别和七个传播途径,在这里我就不多赘述了,感兴趣的小伙伴可以去Goodle了解下,这里我把事务的四个隔离级别贴一下吧.

事务的四个隔离级别"
由低 - -高排序

Read uncommitted

读未提交，顾名思义，就是一个事务可以读取另一个未提交事务的数据。

事例：老板要给程序员发工资，程序员的工资是3.6万/月。但是发工资时老板不小心按错了数字，按成3.9万/月，该钱已经打到程序员的户口，但是事务还没有提交，就在这时，程序员去查看自己这个月的工资，发现比往常多了3千元，以为涨工资了非常高兴。但是老板及时发现了不对，马上回滚差点就提交了的事务，将数字改成3.6万再提交。

分析：实际程序员这个月的工资还是3.6万，但是程序员看到的是3.9万。他看到的是老板还没提交事务时的数据。这就是脏读。

那怎么解决脏读呢？Read committed！读提交，能解决脏读问题。

Read committed

读提交，顾名思义，就是一个事务要等另一个事务提交后才能读取数据。

事例：程序员拿着信用卡去享受生活（卡里当然是只有3.6万），当他买单时（程序员事务开启），收费系统事先检测到他的卡里有3.6万，就在这个时候！！程序员的妻子要把钱全部转出充当家用，并提交。当收费系统准备扣款时，再检测卡里的金额，发现已经没钱了（第二次检测金额当然要等待妻子转出金额事务提交完）。程序员就会很郁闷，明明卡里是有钱的…

更新update的优先级要高于查询
分析：这就是读提交，若有事务对数据进行更新（UPDATE）操作时，读操作事务要等待这个更新操作事务提交后才能读取数据，可以解决脏读问题。但在这个事例中，出现了一个事务范围内两个相同的查询却返回了不同数据，这就是不可重复读。

那怎么解决可能的不可重复读问题？Repeatable read ！

Repeatable read

重复读，就是在开始读取数据（事务开启）时，不再允许修改操作

事例：程序员拿着信用卡去享受生活（卡里当然是只有3.6万），当他埋单时（事务开启，不允许其他事务的UPDATE修改操作），收费系统事先检测到他的卡里有3.6万。这个时候他的妻子不能转出金额了。接下来收费系统就可以扣款了。

分析：重复读可以解决不可重复读问题。写到这里，应该明白的一点就是，不可重复读对应的是修改，即UPDATE操作。但是可能还会有幻读问题。因为幻读问题对应的是插入INSERT操作，而不是UPDATE操作。

什么时候会出现幻读？

事例：程序员某一天去消费，花了2千元，然后他的妻子去查看他今天的消费记录（全表扫描FTS，妻子事务开启），看到确实是花了2千元，就在这个时候，程序员花了1万买了一部电脑，即新增INSERT了一条消费记录，并提交。当妻子打印程序员的消费记录清单时（妻子事务提交），发现花了1.2万元，似乎出现了幻觉，这就是幻读。

那怎么解决幻读问题？Serializable！