- 在MySQL当中，只有使用了InnoDB存储引擎的数据库表才支持事务。
- 有了事务就可以用来保证数据的完整以及一致性，保证成批的SQL语句要么全部执行，要么全部不执行。
- 事务用来管理insert、update、delete语句。
1、四个特性（ACID）：
- 原子性：一个事务（transaction）中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。
- 一致性：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设规则，这包含资料的精确度、串联性以及后续数据库可以自发性地完成预定的工作。
- 隔离性：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括读未提交（Read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（Serializable）。
- 持久性：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。
在 MySQL 命令行的默认设置下，事务都是自动提交的，即执行 SQL 语句后就会马上执行 COMMIT 操作。因此要显式地开启一个事务务须使用命令 BEGIN 或 START TRANSACTION，或者执行命令 SET AUTOCOMMIT=0，用来禁止使用当前会话的自动提交。
2、隔离级别
- 读未提交（Read uncommitted），一个事务可以读取到其他事务中做出操作且还未提交的数据。会出现脏读，不可重复读，幻读现象。
- 读已提交（Read committed），一个事务只能读取到其他事务中做出操作且已经做出提交的数据。会出现不可重复度，幻读现象。
- 可重复读（Repeatable read），同一个事务内多次查询的数据保持一致。会出现幻读
- 串行化（Serializable ）是高的隔离级别,它求在选定对象上的读锁和写锁保持直到事务结束后才能释放,所以能防住上诉所有问题,但因为是串行化的,所以效率较低.
3、幻读、不可重复读、脏读
脏读：当一个事务读取到其他事务还未提交的数据，因为未提交的数据，不一定是最终有效的数据。所以我们称为读到脏数据了。也就是脏读。
不可重复读：一个事务A读取数据之后，另外一个事务B将此数据修改，此时事务A再次查询，发现数据不一样了。这就是不可重复读。也可以叫做幻读。
幻读：又叫"幻象读",是''不可重复读''的一种特殊场景：当事务1两次执行''SELECT ... WHERE''检索一定范围内数据的操作中间，事务2在这个表中创建了(如[[INSERT]])了一行新数据，这条新数据正好满足事务1的“WHERE”子句。
注：可能有点绕，一般情况下，“不可重复读”和“幻读”大致的意思相同。只不过不可重复度是在数据行上发生的，也就是发生了update操作，再去读取这条数据，出现不可重复读。而幻读是在数据表上发生的，也就是发生了insert与delete操作。再去读取这张表，出现数据条目或者行数（记录数）不一样。出现了幻觉一样。
4、MVCC（Multiversion Concurrency Control）多版本并发控制
数据库用于处理读写冲突的一种手段，目的在于提交数据库高并发场景下的吞吐性能。
版本链：
对于使用InnoDB存储引擎的表来说，它的聚簇索引记录中都包含两个必要的隐藏列（row_id并不是必要的，我们
创建的表中有主键或者非NULL唯一键时都不会包含row_id列）：
trx_id：每次对某条记录进行改动时，都会把对应的事务id赋值给trx_id隐藏列。
roll_pointer：每次对某条记录进行改动时，这个隐藏列会存一个指针，可以通过这个指针找到该记
录修改前的信息。
比如说现在有这样一张表：t
ID |
Name |
1 |
小李 |
我们先假设新增这条记录的事务ID为80，那么此时此刻这条记录的版本链表如下图（因为是新增，所以这条版本链对应的roll_pointer是空）：
假如现在有两个事务ID分别为100、200，对这条记录进行update操作，具体走向流程如下：
贴心小课堂:
两个事务中不能交叉更新同一条记录哦？第一个事务更新了某条记录后，就会给这条记录加锁，另一个事务再次更新时就需要等待第一个事务提交了，把锁释放之后才可以继续更新。
我们每一次对数据记录的改动，MySQL都会记录一条日志，我们把它称作undo日志，每一条undo日志对应着也都有一个roll_pointer属性（insert操作对应的undo日志没有该属性，因为该记录并没有更早的版本），可以将这些undo日志都连起来，串成一个链表，所以现在的情况就像下图一样：
对这条记录每次更新后，都会将旧记录放入到undo日志中，就算是该记录的一个历史版本，随着更新次数的一次次增加，所有的版本都会被roll_pointer属性连接成一个链表，我们把这个链表称之为【版本链】，版本链的头节点就是当前记录最新的值。另外，每个版本中还包含生成该版本时对应的事务id，这个ID（事务ID）非常重要，后续事务的隔离级别实现原理都是围绕这个ID（事务ID）来的。
ReadView
对于使用【读未提交READ_UNCOMMITTED】这种隔离级别的事务来说，直接读取记录的最新版本就好了，对于使用【串行化SERIALIZABLE】隔离级别的事务来说，使用加锁的方式来访问记录。对于使用【读已提交READ COMMITTED】和【可重复读REPRATABLE_READ】隔离级别的事务来说，就需要用到我们上边所说的【版本链】了，核心的问题就是：我们需要判断版本链中的数据，哪个版本是当前事务可见的。所以设计MySQL官方提出了一个ReadView的概念，这个ReadView中主要包含当前MySQL中还有哪些活跃的读写事务，把它们的事务id放到一个列表中，我们把这个列表命名为为m_ids(一个数组)。这样在我们访问某一条记录时，只需要按照下边的步骤判断记录的某个版本是否可见（官方设计规则哦）：
- 如果被访问版本的trx_id属性值小于m_ids列表中最小的事务id，表明生成该版本的事务在生成ReadView前已经提交，所以该版本可以被当前事务访问。
- 如果被访问版本的trx_id属性值大于m_ids列表中最大的事务id，表明生成该版本的事务在生成ReadView后才生成，所以该版本不可以被当前事务访问。
- 如果被访问版本的trx_id属性值在m_ids列表中最大的事务id和最小事务id之间，那就需要判断一下trx_id属性值是不是在m_ids列表中，如果在，说明创建ReadView时生成该版本的事务还是活跃的，该版本不可以被访问；如果不在，说明创建ReadView时生成该版本的事务已经被提交，该版本可以被访问。
如果某个版本的数据对当前事务不可见的话，那就顺着版本链继续去找下一个版本的数据记录，依然按照我们上边所说的步骤判断数据是否可见，依此类推，一直到版本链中的最后一个版本数据，如果最后一个版本的数据我也不可见的话，那么也就意味着该条记录对该事务不可见，查询结果就不包含该记录。
在MySQL当中，READ COMMITTED（读已提交）和REPEATABLE READ（可重复读）隔离级别的的一个非常大的区别就是它们生成ReadView的时机不同，我们来具体举例看一下喽。
按照上面我们画的版本链，来具体分析一下，这个版本链是怎么一步步生成的，以及我们查询的时候，MySQL是怎么来通过版本链决定数据我们是否可读（可见）的。
--[1]--【READ COMMITTED --- 每次读取数据前都生成一个ReadView】
假设说现在系统里有一个id为100的事务在执行：
# Transaction 100
BEGIN;
UPDATE t SET name = '小B' WHERE id = 1;
UPDATE t SET name = '小C' WHERE id = 1;
# 注意哦：我们这个事务，我并没有提交。没有commit指令哦
# Transaction 200
BEGIN;
# 更新了一些别的表的记录
...
贴心小课堂：事务执行过程中，只有在第一次真正修改记录时（比如使用INSERT、DELETE、UPDATE语句），才会被分配一个单独的事务id，这个事务id是递增的。
此刻，表t中id为1的记录得到的版本链表如下所示：
千万注意，我上面事务100，还没提交哦，我可没有执行commit指令。
假设现在有一个使用READ COMMITTED（读已提交）隔离级别的事务开始执行：
# 使用READ COMMITTED隔离级别的事务（读已提交）
BEGIN;
# SELECT1：Transaction 100、200未提交
SELECT * FROM t WHERE id = 1; # 得到的列name的值为'小A'
这个SELECT1的执行流程如下：
- 在执行SELECT语句时会首先生成一个ReadView，ReadView的m_ids数组列表的内容就是[100,200]。
- 然后从版本链中挑选可见的记录，从图中可以看出，最新版本的列name的内容是'小C'，该版本的trx_id值为100，在m_ids列表内，所以不符合我们的可见性要求，根据roll_pointer跳到下一个版本。
- 下一个版本的列name的内容是'小B'，该版本的trx_id值也为100，也在m_ids列表内，所以也不符合要求，继续跳到下一个版本。
- 下一个版本的列name的内容是'小A'，该版本的trx_id值为80，小于m_ids列表中最小的事务id100，所以这个版本是符合要求的，最后返回给用户的版本就是这条列name为'小A'的记录。
之后，我们把事务id为100的这个事务提交一下，如下：
# Transaction 100
BEGIN;
UPDATE t SET name = '小B' WHERE id = 1;
UPDATE t SET name = '小C' WHERE id = 1;
COMMIT; //提交了哦
然后再到事务id为200的事务中更新一下表t中id为1的记录：
# Transaction 200
BEGIN;
# 更新了一些别的表的记录
...
UPDATE t SET name = '小D' WHERE id = 1;
UPDATE t SET name = '小F' WHERE id = 1;
此刻，表t中id为1的记录的版本链就长这样：
然后再到刚才使用READ COMMITTED隔离级别的事务中继续查找这个id为1的记录，如下：
# 使用READ COMMITTED隔离级别的事务
BEGIN;
# SELECT1：Transaction 100、200均未提交的时候执行的查询
SELECT * FROM t WHERE id = 1; # 得到的列name的值为'小A'
# SELECT2：Transaction 100提交，Transaction 200未提交的时候执行的查询
SELECT * FROM t WHERE id = 1; # 得到的列name的值为'小C'
这个SELECT2的执行过程如下：
- 在执行SELECT语句时会先生成一个ReadView，ReadView的m_ids列表的内容就是[200]（事务id为100的那个事务已经提交了，所以生成快照时就没有它了）。
- 然后从版本链中挑选可见的记录，从图中可以看出，最新版本的列name的内容是'小F'，该版本的trx_id值为200，在m_ids列表内，所以不符合可见性要求，根据roll_pointer跳到下一个版本。
- 下一个版本的列name的内容是'小D'，该版本的trx_id值为200，也在m_ids列表内，所以也不符合要求，继续跳到下一个版本。
- 下一个版本的列name的内容是'小C'，该版本的trx_id值为100，比m_ids列表中最小的事务id200还要小，所以这个版本是符合要求的，最后返回给用户的版本就是这条列name为'小C'的记录。
以此类推，如果之后事务id为200的记录也提交了，再此在使用READ COMMITTED隔离级别的事务中查询表t中id值为1的记录时，得到的结果就是'小F'了，具体流程我们就不分析了。总结一下就是：使用READ COMMITTED隔离级别的事务在每次查询开始时都会生成一个独立的ReadView。
说完了隔离级别为【读已提交】不知道你理解了没有？如果不理解，烦请联系我，我们一起进行探讨。
接下来我们就来看一下当事务隔离级别为【可重复读】的时候，MVCC是如何控制数据可见性的。
--[2]--【REPEATABLE READ ---在第一次读取数据时生成一个ReadView】
对于使用REPEATABLE READ隔离级别的事务来说，只会在第一次执行查询语句时生成一个ReadView，之后的查询就不会重复生成了。我们还是用例子看一下是什么效果。
比方说现在系统里有两个id分别为100、200的事务在执行：
# Transaction 100
BEGIN;
UPDATE t SET name = '小B' WHERE id = 1;
UPDATE t SET name = '小C' WHERE id = 1;
# Transaction 200
BEGIN;
# 更新了一些别的表的记录
...
此刻，表t中id为1的记录得到的版本链表如下所示：
假设现在有一个使用REPEATABLE READ隔离级别的事务开始执行：
# 使用REPEATABLE READ隔离级别的事务
BEGIN;
# SELECT1：Transaction 100、200未提交
SELECT * FROM t WHERE id = 1; # 得到的列name的值为'小A'
这个SELECT1的执行过程如下：
- 在执行SELECT语句时会先生成一个ReadView，ReadView的m_ids列表的内容就是[100, 200]。
- 然后从版本链中挑选可见的记录，从图中可以看出，最新版本的列name的内容是'小C'，该版本的trx_id值为100，在m_ids列表内，所以不符合可见性要求，根据roll_pointer跳到下一个版本。
- 下一个版本的列name的内容是'小B'，该版本的trx_id值也为100，也在m_ids列表内，所以也不符合要求，继续跳到下一个版本。
- 下一个版本的列name的内容是'小A'，该版本的trx_id值为80，小于m_ids列表中最小的事务id100，所以这个版本是符合要求的，最后返回给用户的版本就是这条列name为'小A'的记录。
之后，我们把事务id为100的事务提交一下，就像这样：
# Transaction 100
BEGIN;
UPDATE t SET name = '小B' WHERE id = 1;
UPDATE t SET name = '小C' WHERE id = 1;
COMMIT;
然后再到事务id为200的事务中更新一下表t中id为1的记录：
# Transaction 200
BEGIN;
# 更新了一些别的表的记录
...
UPDATE t SET name = '小D' WHERE id = 1;
UPDATE t SET name = '小F' WHERE id = 1;
此刻，表t中id为1的记录的版本链就长这样：
然后再到刚才使用REPEATABLE READ隔离级别的事务中继续查找这个id为1的记录，如下：
# 使用REPEATABLE READ隔离级别的事务
BEGIN;
# SELECT1：Transaction 100、200均未提交
SELECT * FROM t WHERE id = 1; # 得到的列name的值为'小A'
# SELECT2：Transaction 100提交，Transaction 200未提交
SELECT * FROM t WHERE id = 1; # 得到的列name的值仍为'小A'
这个SELECT2的执行过程如下：
- 因为之前已经生成过ReadView了，所以此时直接复用之前的ReadView，之前的ReadView中的m_ids列表就是[100, 200]。
- 然后从版本链中挑选可见的记录，从图中可以看出，最新版本的列name的内容是'小F'，该版本的trx_id值为200，在m_ids列表内，所以不符合可见性要求，根据roll_pointer跳到下一个版本。
- 下一个版本的列name的内容是'小D'，该版本的trx_id值为200，也在m_ids列表内，所以也不符合要求，继续跳到下一个版本。
- 下一个版本的列name的内容是'小C'，该版本的trx_id值为100，而m_ids列表中是包含值为100的事务id的，所以该版本也不符合要求，同理下一个列name的内容是'小B'的版本也不符合要求。继续跳到下一个版本。
- 下一个版本的列name的内容是'小A'，该版本的trx_id值为80，80小于m_ids列表中最小的事务id100，所以这个版本是符合要求的，最后返回给用户的版本就是这条列name为'小A'的记录。
也就是说我们的两次SELECT查询得到的数据结果是一样(重复)的，列name值都是'小A'，这就是【可重复读】的含义。如果我们之后再把事务id为200的记录也提交了，之后再到刚才使用REPEATABLE READ隔离级别的事务中继续查找这个id为1的记录，得到的结果还是'小A'。
MVCC总结
从上边的描述中我们可以看出来，所谓的MVCC（Multi-Version Concurrency Control ，多版本并发控制）指的就是在使用READ COMMITTD、REPEATABLE READ这两种隔离级别的事务在执行普通的SEELCT操作时访问记录的版本链的过程，这样就可以使不同事务的读-写、写-读操作并发执行，从而提升系统性能。READ COMMITTD、REPEATABLE READ这两个隔离级别的一个很大不同就是生成ReadView的时机不同，READ COMMITTD在每一次进行普通SELECT操作前都会生成一个ReadView，而REPEATABLE READ只在第一次进行普通SELECT操作前生成一个ReadView，之后的查询操作都重复这个ReadView就好了。
回到我们的标题：
MySQL到底能不能解决幻读？或者说MySQL是如何解决幻读的？
现在你明白了吗？
欢迎一起讨论
