跟着项目学sql——数据库事物(1)

数据库事务是构成单一逻辑工作单元的操作集合，构成逻辑整体的这些数据库操作,要么全部执行成功,要么全部不执行,是一个不可分割的工作单位。

好吧，上面还是百度百科里的一段定义，扒过来撑场面的。sql从数据库事物开始就已经进入到非常难以讲解的地步了。并不是说数据库事物本身的定义有多难理解，而是数据库事物的应用场景实在是不好找！

来看一下有关数据库事物的许多文章中几乎已经被用烂的例子：

转账是生活中常见的操作,比如从A账户转账100元到B账户。站在用户角度而言,这是一个逻辑上的单一操作,然而在数据库系统中,至少会分成两个步骤来完成:

• 1.将A账户的金额减少100元
• 2.将B账户的金额增加100元。

   在这个过程中可能会出现以下问题:

1.转账操作的第一步执行成功,A账户上的钱减少了100元,但是第二步执行失败或者未执行便发生系统崩溃,导致B账户并没有相应增加100元。

2.转账操作刚完成就发生系统崩溃,系统重启恢复时丢失了崩溃前的转账记录。

3.同时有另一个用户转账给B账户,由于同时对B账户进行操作,导致B账户金额出现异常。

为了便于解决这些问题,需要引入数据库事务的概念。

这个被强行创造出的例子其实和【用单例模式搞网站计数器】没啥区别，只是因为数据库事物的应用场景实在是不好找，无奈之下的选择。很牵强，不明确，容易误导新人。下面来驳斥一下这个例子：

第一：转账这个操作很明显你单靠一个【账户表】是根本就摆不平业务需求的！至少要有账户表+流水表，用户的账户余额完全可以通过计算流水表获得的呀，这才叫做转账呀！你单靠一个账户表+事物根本就完不成转帐这个功能，那和前文提到的用单例模式做网站计数器的例子如出一辙，完全满足不了需求！

           从关系型数据库的视角来看，用单例模式做网站计数器：

1)用户每次访问+1，如果网站重启，归零了。

2)因为缺少访问记录表，所以最终无法证明计数器的准确性。

计数器在视频网站，电商网站中的作用至关重要，为了保证数据的实时性，并发量很大的情况下对访问记录表的频繁操作是对性能的挑战。所以结论就是单例模式是【很给力的设计模式】，而网站计数器【至关重要】，二者结合要考虑到必要的数据持久化，基数纠正等一系列问题。

单靠一个【账户表】做转账：

1)转出100元，转入100元=没有操作

2)这种单表复杂操作，因为业务没整对，争抢同一个资源【余额】，肯定会死锁，

3)而且【同时有另一个用户转账给B账户,由于同时对B账户进行操作,导致B账户金额出现异常】这种情况用数据库事物根本就解决不了。 

tip: c初始0元。a，b同时转100给c。那么：

a转入100，b读到100，a崩溃回滚=多100，game over；

a转入100，b读到0，a，b都执行成功=少100，game over；

因此只能将该操作提升至锁表，并发操作变为串行操作，避开这些问题。

第二：转账是生活中常见的操作,比如从A账户转账100元到B账户。你这里既然提到了【生活中常见的操作】，那就拿笔者来说吧，工行工资卡转到支付宝，工行的工资卡转给北京银行的理财卡，这些操作每个月都会发生，可笔者并没有因为上面提到的系统崩溃或者并发问题损失一分钱，这当然是【事物】的功劳，但和你所说的【数据库事物】没有任何关系！

因为无论是工资卡转到支付宝，还是工资卡转给理财卡，如果强行要求这个操作就必须是用数据库来实现的，那笔者转账操作至少是一个跨数据库了的操作了，而且最少是跨服务器跨库，而且还很可能不是同一种数据库——跨服务器跨库这边工资卡用的oracle，那边理财卡用的mysql，这种情况下你的数据库事物太渺小了，到底要怎么提交？又怎么回滚呢？你所说的数据库事物的作用已经荡然无存！哪里有【数据库事物】，分明就只有【事物】。

当然，你可能会说这是比较复杂的情况，那笔者就说一种特别特别简单的情况吧：

A账户存储在mysql里的一个库，而B帐户存储在一个excel文件里，好了，.转账操作刚完成就发生系统崩溃,A账户回滚，B账户的Excel文件是不是也要回滚？你用你的数据库事物把B账户回滚一个看看？滚呀，怎么滚不动了？

所以呢，笔者的【跟着项目学】系列是最适合作为硬干货来学习的，因为跟着项目走，所有的应用场景都是对的上的，简单明了，不误导人。

待续。。。