理解篇——mysql 我所理解的事务

仅个人理解

可以直接简洁明了的概括：保持数据的安全实现。

事务就是为了数据的安全交互保驾护航，从这个目的来讲事务的应用很广泛，在数据库工作过程中会发生种种变数，而事务的存在就是要做到以不变应万变，起到 “ 只要在数据交互的过程中你使用了事务，你尽管运行，我保证所有你担心的问题我都可以处理 ”效果。

那么数据库在工作过程中会遇到哪些问题？又期待在遇到问题的时候数据应该保持怎样的状态？

（1）数据——业务的完整实现需求

是先有数据？还是先有事务？当然，一定是先有数据，事务仅仅是为数据服务的仆人，日夜围着数据转，当我们分析事务时，一定要先理解事务所围绕的对象：数据，换句话说：业务（数据交互）。

数据库：为业务处理而生。

一个好的数据库在形成的过程中一定是对通用的数据业务非常熟悉的，企业的业务活动中如何建表？如何将业务转换为对表的操作？

以一个很经典的业务场景为例，转账业务，这也是我们理解事务的一致性和原子性特点过程中比较熟悉的场景。

这里我们不再去分析这个场景，而是从这个场景中获得一些启发：

数据库在处理数据过程中操作的逻辑单位是一条数据吗？
在这个场景看来并不是，如果操作的逻辑单位是一条数据的修改，一个转账业务涉及到两条数据的修改，一个账户的增，另一个账户的减，如果此时发生一条操作成功，那么另外一条操作失败，这就没有满足业务的需要，没有满足业务的需要，说明你这个数据库系统就不是一个合格的数据库系统，你没有对通用的业务场景做技术支撑。

好的，我们的事务就先从这里开始，解决数据库运行过程中的第一个问题：满足业务必须完整实现的需求。

封装有限的数据库操作序列构成数据库管理系统(DBMS)执行过程中的一个逻辑单位。

这是事务的原子性特点，是对现实世界业务活动需要一系列有完整逻辑意义的数据读写操作所提供的支撑，说白了，在需要数据库处理数据的地方就有业务必须完整执行成功的场景。

事务的一致性个人认为也是业务活动完整实现需求的一部分，当数据的处理不再是以一条数据为操作单元，而是以一个完整的业务活动，即一系列有完整逻辑意义的数据读写操作为操作单元，这其中就包含了对于前后状态的判断。

举例来说：

当以一条数据为操作单元时。

UPDATE CMBC SET balance = balance - 1000000.00 WHERE username = 'lemon';

这条操作是没有任何现实意义的，因为这一条数据根本就支撑不起来现实业务活动，还是那句话，数据库是为业务服务的，是为人类现实活动服务的，技术不是高高在上，不是一段一段冰冷的代码，而是围绕着现实活动转的，转账业务你要转1000000给别人，取钱业务你要取1000000，在这之前是必须查看你是否有足够的余额，这样一个业务必须是如下的一系列数据读写操作支撑。

select balance from CMBC username = 'lemon'; 
if(balance > 10000000){
	try{
	UPDATE CMBC SET balance = balance - 1000000.00 WHERE username = 'lemon';
	} catch {
		 //对业务的实现异常进行处理
		}
	}

不仅仅是资金往来业务，也不仅仅必须是人类现实活动，或许在某个场景下就不需要查询你的余额是否足够，但是这样一种思想：一个完整业务实现的过程中必须包括对前后状态的判断，这样一个场景不论是在哪里都是会遇到的，为什么？因为运动的过程是包含变化的，变化会产生不同的状态，数据交互的过程必须要面临捕获这些状态的场景，这是世界的规律，任何专业的尽头都是哲学，因为我们身处这个世界，即使你不知道重力，但是你确实时时刻刻在重力的作用下。

（2） 数据——业务的并发实现需求

并发，让人又爱又恨的并发，并发（并行）通过对硬件的最大化利用进一步加速运行，这很好，但是有了并发，又产生了并发的一系列问题，你需要学习线程安全、锁（其中又涵盖了n个知识细节）、异步编程等等，不过这些也没有关系，人的潜力是无穷的，而硬件的资源是有限的，将人的学习成本与性能等价交换（如果确实有意义的话）。

刚才提到以一系列有完整逻辑意义的数据读写操作为操作单元，也就是一个事务为操作单元，事务本身也是可以并发的，那老生常谈了，并发情况下你必须要解决由此而来的问题。

临界资源的修改问题

同一条数据，在操作单元为一条记录而不是一个事务的情况下，我们可以通过加锁保证操作的原子性。

但是如果操作单元为一个事务，好了，这下mysql因为自己使用事务同时又使用并发产生全新的问题，这些问题我们也很熟悉：可重复读、幻读等等，mysql贴心的通过隔离级别来减少这些问题，可惜只有你使用串行化这种最高隔离级别（说白了不用并发）才会不出问题，也就是说只要你使用并发，你就必须面临这些问题。

这就是事务 ACID特性中的隔离性概念。

（3） 数据——业务的持久化实现需求

事务的持久性没什么可说的，不管是sql还是nosql，只要你是数据库，你就面临将数据持久化的需求场景。

附录

一些官方说明

https://www.mysqltutorial.org/

MySQL transaction allows you to execute a set of MySQL operations to ensure that the database never contains the result of partial operations. In a set of operations, if one of them fails, the rollback occurs to restore the database to its original state. If no error occurs, the entire set of statements is committed to the database.

其实就是实现以业务逻辑为执行单元。

Mysql 8.0

Transactions are atomic units of work that can be committed or rolled back. When a transaction makes multiple changes to the database, either all the changes succeed when the transaction is committed, or all the changes are undone when the transaction is rolled back.

Database transactions, as implemented by InnoDB, have properties that are collectively known by the acronym ACID, for atomicity, consistency, isolation, and durability.

事务的ACID

ACID
An acronym standing for atomicity, consistency, isolation, and durability. These properties are all desirable in a database system, and are all closely tied to the notion of a transaction. The transactional features of InnoDB adhere to the ACID principles.

Transactions are atomic units of work that can be committed or rolled back. When a transaction makes multiple changes to the database, either all the changes succeed when the transaction is committed, or all the changes are undone when the transaction is rolled back.

事务的原子性就如原子操作一般，表示事务不可再分，其中的操作要么都做，要么都不做；如果事务中一个SQL语句执行失败，则已执行的语句也必须回滚，数据库退回到事务前的状态。只有0和1，没有其它值。
事务的原子性表明事务就是一个整体，当事务无法成功执行的时候，需要将事务中已经执行过的语句全部回滚，使得数据库回归到最初未开始事务的状态。
事务的原子性就是通过undo log日志进行实现的。当事务需要进行回滚时，InnoDB引擎就会调用undo log日志进行SQL语句的撤销，实现数据的回滚。

The database remains in a consistent state at all times — after each commit or rollback, and while transactions are in progress. If related data is being updated across multiple tables, queries see either all old values or all new values, not a mix of old and new values.

事务前后的状态都是正确、合理的状态
事务的一致性是通过原子性、隔离性等实现，事务的一致性是一个宽泛的约束，确切的说是一种最终目的，当数据的变更过程正常，就可以实现这个目的，而数据的变更过程正常需要事务实现原子性、隔离性等。

Transactions are protected (isolated) from each other while they are in progress; they cannot interfere with each other or see each other’s uncommitted data. This isolation is achieved through the locking mechanism. Experienced users can adjust the isolation level, trading off less protection in favor of increased performance and concurrency, when they can be sure that the transactions really do not interfere with each other.

数据库系统提供一定的隔离机制，保证事务在不受外部并发操作影响的“独立”环境执行。这意味着事务处理过程中的中间状态对外部是不可见的，反之亦然。
隔离性是事务ACID特性中最复杂的一个。在SQL标准里定义了四种隔离级别，每一种隔离级别都规定一个事务中的修改，那些是事务之间可见的，那些是不可见的。

The results of transactions are durable: once a commit operation succeeds, the changes made by that transaction are safe from power failures, system crashes, race conditions, or other potential dangers that many non-database applications are vulnerable to. Durability typically involves writing to disk storage, with a certain amount of redundancy to protect against power failures or software crashes during write operations. (In InnoDB, the doublewrite buffer assists with durability.)