对于MySQL数据库一致性的理解

事务的产生

首先,我们需要搞清楚为什么会出现事务.

Transactions are not a law of nature; they were created with a purpose, namely to simplify the programming model for applications accessing a database. By using transactions, the application is free to ignore certain potential error scenarios and concurrency issues, because the database takes care of them instead (we call these safety guarantees).

这段文字大体含义就是,事务的产生,其实是为了当应用程序访问数据库的时候,事务能够简化我们的编程模型,不需要我们去考虑各种各样的潜在错误和并发问题.可以想一下当我们使用事务时,要么提交,要么回滚,我们不会去考虑网络异常了,服务器宕机了,同时更改一个数据怎么办对吧?因此事务本质上是为了应用层服务的.而不是伴随着数据库系统天生就有的

事务的四大特性

事务就是一组原子性的SQL操作或者一个独立的工作单元，事务内的语句要么全部执行成功，要么全部执行失败。
事务是指对系统进行的一组操作，为了保证系统的完整性，事务具有ACID特性，具体如下：

原子性（Atomic）
一个事务包含多个操作，这些操作要么全部执行，要么全都不执行
实现事务的原子性，是基于日志的Redo/Undo机制

一致性（Consistency）
一致性是指事务使得系统从一个一致的状态转换到另一个一致状态。 事务的一致性决定了一个系统设计和实现的复杂度，也导致了事务的不同隔离级别。

隔离性（Isolation）
隔离性侧重指事务之间相互隔离，不受影响，这个与事务设置的隔离级别有密切的关系。

持久性（Durability）
事务提交后，对系统的影响是永久的。

简单理解一致性
看到网上有文章说，事务的AID是数据库的特征，也就是依赖数据库的具体实现。而唯独这个C，实际上它依赖于应用层，也就是依赖于开发者。
这里的一致性，是指数据从一种正确的状态，跳转到另一种正确的状态。什么是正确的状态？这就涉及到数据库库表设计以及应用层代码逻辑。拿最简单的转账来说明：

账户A转1000到账户B
应用逻辑上的正确性：
1.账户A和账户B在此次事务执行前后（不考虑其他事务对AB账号的操作），账户余额总和的一致性；
2.A转账的金额，必须小于等于自己的账户余额，即事务提交时，A的账户余额不能为负数（可以通过数据库约束，保证账户jine的字段值大于等于0）。
数据库设计上的正确性：
1.账户余额字段，可能在设计的时候，存在数值大小的约束，那么在事务提交时，B的账户余额不能超出这个范围
、
简单理解：转账过程中，如果未满足以上的任意一项，那么为保证事务的一致性，数据库操作失败，事务回滚，回到最初的正确状态。

其中，事务的一致性决定了一个系统设计和实现的复杂度，导致了事务的不同隔离级别；在事务的并发的时候，隔离性设计的脏读、幻读等等。
想要了解更多更详细的，可以从下面的传送门去看下：