我们设想一个场景，这个场景中我们需要插入多条相关联的数据到数据库，不幸的是，这个过程可能会遇到下面这些问题：
- 数据库中途突然因为某些原因挂掉了。
- 客户端突然因为网络原因连接不上数据库了。
- 并发访问数据库时，多个线程同时写入数据库，覆盖了彼此的更改。
- …
有想赚点外块|技术交流的朋友，欢迎来撩
上面的任何一个问题都可能会导致数据的不一致性。为了保证数据的一致性，系统必须能够处理这些问题。事务就是我们抽象出来简化这些问题的首选机制。
事务的概念起源于数据库，目前已经成为一个比较广泛的概念。
何谓事务？
一个事情由n个单元组成，这n个单元在执行过程中，要么同时成功，要么同时失败，这就把n个单元放在了一个事务之中。
举个简单的例子：在不考虑试题正确与否的前提下，一张试卷由多个题目构成，当你答完题交给老师的时候是将一整张试卷交给老师，而不是将每道题单独交给老师，在这里试卷就可以理解成一个事务。
事务的特性：ACID
A：原子性（Atomicity），原子性是指事务是一个不可分割的工作单位，事务中的操作，要么都发生，要么都不发生。
例：假设你在购物车里添加了两件衣服：上衣和裤子，当你把两件衣服作为一个订单提交支付的时候，要么两件衣服一起支付成功，要么都失败，不可能存在上衣付完钱了，裤子还没付完的情况，反之亦然。
C：一致性（Consistency），在一个事务中，事务前后数据的完整性必须保持一致。
例：假设用户A和用户B两者的钱加起来一共是200，那么不管A和B之间如何转账，转几次账，事务结束后两个用户的钱相加起来应该还得是200，这就是事务的一致性。
I：隔离性（Isolation），存在于多个事务中，事务的隔离性是指多个用户并发访问数据库时，一个用户的事务不能被其它用户的事务所干扰，多个并发事务之间数据要相互隔离。
例：对于任意两个并发的事务T1和T2，在事务T1看来，T2要么在T1开始之前就已经结束，要么在T1结束之后才开始，这样每个事务都感觉不到有其他事务在并发地执行。
D：持久性（Durability），持久性是指一个事务一旦被提交，它对数据库中数据的改变就是永久性的，接下来即使数据库发生故障也不应该对其有任何影响。
例：我们在操作数据库时，事务提交或者回滚都会直接改变数据库中的值。
AID是手段，C是目的，AID都是为了保证数据的一致性。
事务的操作
在使用事务之前，首先我们要开启事务，我们可以通过start或者begin命令开启事务；如果我们想提交事务可以手动执行commit命令，如果我们想回滚事务，可以执行rollback命令。
# 开启一个事务START TRANSACTION;# 多条 SQL 语句SQL1,SQL2...## 提交事务COMMIT;
注：在MySQL中事务的提交是默认开启的，可以执行show variables like 'autocommit'命令查看，如果是ON则证明自动提交已经开启，如果为OFF则需要手动提交。
隔离性引发的并发问题
1）脏读：B事务读取到了A事务尚未提交的数据；
一个事务读取数据并且对数据进行了修改，这个修改对其他事务来说是可见的，即使当前事务没有提交。这时另外一个事务读取了这个还未提交的数据，但第一个事务突然回滚，导致数据并没有被提交到数据库，那第二个事务读取到的就是脏数据，这也就是脏读的由来。
2）不可重复读：B事务读到了A事务已经提交的数据，即B事务在A事务提交之前和提交之后读取到的数据内容不一致（AB事务操作的是同一条数据）；
事务 1 读取某表中的数据 A=20，事务 2 也读取 A=20，事务 1 修改 A=A-1，事务 2 再次读取 A =19，此时读取的结果和第一次读取的结果不同。
3）幻读/虚读：B事务读到了A事务已经提交的数据，即A事务执行插入操作，B事务在A事务前后读到的数据数量不一致。
事务 2 读取某个范围的数据，事务 1 在这个范围插入了新的数据，事务 2 再次读取这个范围的数据发现相比于第一次读取的结果多了新的数据。
不可重复读和幻读有什么区别
- 不可重复读的重点是内容修改或者记录减少比如多次读取一条记录发现其中某些记录的值被修改；
- 幻读的重点在于记录新增比如多次执行同一条查询语句（DQL）时，发现查到的记录增加了。
幻读其实可以看作是不可重复读的一种特殊情况，单独把区分幻读的原因主要是解决幻读和不可重复读的方案不一样。
举个例子：执行 delete 和 update 操作的时候，可以直接对记录加锁，保证事务安全。而执行 insert 操作的时候，由于记录锁（Record Lock）只能锁住已经存在的记录，为了避免插入新记录，需要依赖间隙锁（Gap Lock）。也就是说执行 insert 操作的时候需要依赖 Next-Key Lock（Record Lock+Gap Lock） 进行加锁来保证不出现幻读。
事务的隔离级别
为了解决以上隔离性引发的并发问题，数据库提供了事物的隔离机制。
- read uncommitted（读未提交）: 一个事务还没提交时，它做的变更就能被别的事务看到，读取尚未提交的数据，哪个问题都不能解决；
- read committed（读已提交）：一个事务提交之后，它做的变更才会被其他事务看到，读取已经提交的数据，可以解决脏读 ----
oracle默认的； - repeatable read（可重复读）：一个事务执行过程中看到的数据，总是跟这个事务在启动时看到的数据是一致的，可以解决脏读和不可重复读 —
mysql默认的； - serializable（串行化）：顾名思义是对于同一行记录，“写”会加“写锁”，“读”会加“读锁”。当出现读写锁冲突的时候，后访问的事务必须等前一个事务执行完成，才能继续执行。可以解决脏读、不可重复读和虚读—相当于锁表。
虽然serializable级别可以解决所有的数据库并发问题，但是它会在读取的每一行数据上都加锁，这就可能导致大量的超时和锁竞争问题，从而导致效率下降。所以我们在实际应用中也很少使用serializable，只有在非常需要确保数据的一致性而且可以接受没有并发的情况下，才考虑采用该级别。
MySQL 的隔离级别是基于锁实现的吗？
MySQL 的隔离级别基于锁和 MVCC 机制共同实现的。
SERIALIZABLE 隔离级别是通过锁来实现的，READ-COMMITTED 和 REPEATABLE-READ 隔离级别是基于 MVCC 实现的。不过， SERIALIZABLE 之外的其他隔离级别可能也需要用到锁机制，就比如 REPEATABLE-READ 在当前读情况下需要使用加锁读来保证不会出现幻读。
默认隔离级别
MySQL InnoDB 存储引擎的默认支持的隔离级别是 REPEATABLE-READ（可重复读）。我们可以通过 SELECT @@tx_isolation;命令来查看，MySQL 8.0 该命令改为SELECT @@transaction_isolation;
mysql> SELECT @@tx_isolation;+-----------------+| @@tx_isolation |+-----------------+| REPEATABLE-READ |+-----------------+从上面对 SQL 标准定义了四个隔离级别的介绍可以看出，标准的 SQL 隔离级别定义里，REPEATABLE-READ(可重复读)是不可以防止幻读的。
但是 InnoDB 实现的 REPEATABLE-READ 隔离级别其实是可以解决幻读问题发生的，主要有下面两种情况：
- 快照读 ：由 MVCC 机制来保证不出现幻读。
- 当前读 ：使用 Next-Key Lock（临键锁） 进行加锁来保证不出现幻读，Next-Key Lock 是行锁（Record Lock）和间隙锁（Gap Lock）的结合，行锁只能锁住已经存在的行，为了避免插入新行，需要依赖间隙锁。
InnoDB 存储引擎在分布式事务的情况下一般会用到 SERIALIZABLE 隔离级别。
解决幻读的方法
解决幻读的方式有很多，但是它们的核心思想就是一个事务在操作某张表数据的时候，另外一个事务不允许新增或者删除这张表中的数据了。解决幻读的方式主要有以下几种：
- 将事务隔离级别调整为 SERIALIZABLE 。
- 在可重复读的事务级别下，给事务操作的这张表添加表锁。
- 在可重复读的事务级别下，给事务操作的这张表添加 Next-key Lock（Record Lock+Gap Lock）
总结
看到这，你对事务是否已经有了清晰的认识？接下来我们就简单总结下今天的知识点：
- 事务的概念：一个事情由n个单元组成，这n个单元在执行过程中，要么同时成功，要么同时失败，这就把n个单元放在了一个事务之中。
- 事务的特性：ACID
- 事务的操作：开启事务、提交事务、回滚事务
- 事务的隔离级别：读未提交、读已提交、可重复读、串行化
- 解决幻读的方法：锁机制和MVCC机制
来源地址：https://blog.csdn.net/Qingai521/article/details/131287819
