• 在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是空）：

MySQL中的MVCC到底能不能解决幻读
假如现在有两个业务ID分别为100、200，对这条记载进行update操作，详细走向流程如下：
MySQL中的MVCC到底能不能解决幻读

贴心小讲堂:
两个业务中不能交叉更新同一条记载哦？第一个业务更新了某条记载后，就会给这条记载加锁，另一个业务再次更新时就需求等候第一个业务提交了，把锁开释之后才能够持续更新。

咱们每一次对数据记载的改动，MySQL都会记载一条日志，咱们把它称作undo日志，每一条undo日志对应着也都有一个roll_pointer特点（insert操作对应的undo日志没有该特点，由于该记载并没有更早的版别），能够将这些undo日志都连起来，串成一个链表，所以现在的情况就像下图相同：

MySQL中的MVCC到底能不能解决幻读
对这条记载每次更新后，都会将旧记载放入到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]–【R****EAD 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的记载得到的版别链表如下所示：

MySQL中的MVCC到底能不能解决幻读
千万留意，我上面业务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的记载的版别链就长这样：

MySQL中的MVCC到底能不能解决幻读
然后再到方才运用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的记载得到的版别链表如下所示：

MySQL中的MVCC到底能不能解决幻读
假定现在有一个运用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的记载的版别链就长这样：

MySQL中的MVCC到底能不能解决幻读
然后再到方才运用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是如何处理幻读的？ 现在你理解了吗？ 欢迎一同评论

本文正在参与「技能专题19期 漫谈数据库技能」活动