事务就是一组原子性的SQL查询(或者说是一个独立的工作单元).
事务内的语句,要么全部执行成功,要么全部执行失败.

银行转账是一个经典例子.
要从1024号用户转账两百元给2048用户,至少需要三个步骤

1.先检查转出人余额是否足够.
2.从1024号用户余额减去200.
3.给2048号用户增加200.

1    START TRANSACTION;

2    SELECT balance FROM checking WHERE customer_id = 1024;

3    UPDATE checking SET balance = balance - 200.00 WHERE customer_id = 1024;

4    UPDATE checking SET balance = balance + 200.00 WHERE customer_id = 2048;

5    COMMIT;

但是事务的概念没有这么单纯,如果执行到第四句时服务器奔溃了,用户1024可能会拜拜损失两百.
或者执行到第三句和第四句之间,另外一个进程要提现清空2048用户的所有余额,那这时候,可能2048又白白得到了两百元?

所以除非系统通过严格的ACID测试,否则空谈事务的概念不够的,ACID表示原子性,一致性,隔离性,和持久性,一个运行良好的事务处理系统,必须具备这些标准特征.

ACID的概念

A 原子性 atomicity
一个事务必须被视为一个不可分割的 最小工作单元, 整个事务中所有的操作要么全部提交成功,要么全部失败回滚,对于一个事务来说,不可能只执行其中的一部分

C 一致性 consistency
数据库总是从一个一致性的状态转换为另外一个一致性的状态.
一致性确保了,要么全部成功,要么全部失败,所以在数条语句之间系统崩溃,也不会有损失,因为事务最终没有提交,所以事务所做的修改也不会保存到数据库中.

I 隔离性 isolation
通常来说,一个事务所做的修改在最终提交以前,对其他事务是不可见的.
在前面的例子中,当执行完第三条语句,第四条还没开始的时候,如果此时有另外一个进程在查询1024用户的余额可以看到并没有被减去200.
但是这里是说通常情况下,之后会在 隔离级别中说道为什么是"通常来说".

D 持久性 durability
一旦事务提交,则其所做的修改就会永久保存到数据库中.此时即便系统崩溃,修改的数据也不会丢失. (实际上,持久性也分很多不同的级别.有的能提供非常强的安全保障,而有些则未必.而且不可能有能做到100%的持久性保证的策略.就像我们通常还要对数据库做备份以防万一.)

事务的ACID特性可以保证银行不会弄丢我们的钱.但是在应用逻辑中,要实现这一点非常难,甚至可以说是不可能完成的任务.一个兼容ACID的数据库系统,需要做很多非常复杂但是用户并没有察觉到的工作,才能实现ACID的实现.

然而就像锁粒度的升级会增加系统开销一样,这种事务处理过程中额外的安全性,也会需要数据库系统做更多的额外工作.一个实现了ACID的数据库,相比没有实现ACID的数据库库,通常会需要更强的CPU处理能力,更大的内存和更多的磁盘空间.所以我们可以根据业务是否需要事务处理来选择合适的储存引擎.
对于一些不需要事务的查询类应用,选择一个非事务类型的储存引擎,可以获得更高的性能.即使储存引擎不支持事务也可以通过LOCK TABLES语句来为应用提供有一定程度的保护,这些都可以自主选择.

最后修改:2021 年 03 月 06 日 07 : 20 PM
随便看看就好,打赏个一毛两毛也不错