MySQL事务的12连问

事务的12连问，相信大家看完肯定会有帮助的。

1. 什么是数据库事务？

事务，由一个有限的数据库操作序列构成，这些操作要么全部执行,要么全部不执行，是一个不可分割的工作单位。

假如A转账给B 100 元，先从A的账户里扣除 100 元，再在 B 的账户上加上 100 元。如果扣完A的100元后，还没来得及给B加上，银行系统异常了，最后导致A的余额减少了，B的余额却没有增加。所以就需要事务，将A的钱回滚回去，就是这么简单。

2. 事务的四大特性

原子性：事务作为一个整体被执行，包含在其中的对数据库的操作要么全部都执行，要么都不执行。
一致性：指在事务开始之前和事务结束以后，数据不会被破坏，假如A账户给B账户转10块钱，不管成功与否，A和B的总金额是不变的。
隔离性：多个事务并发访问时，事务之间是相互隔离的，一个事务不应该被其他事务干扰，多个并发事务之间要相互隔离。
持久性：表示事务完成提交后，该事务对数据库所作的操作更改，将持久地保存在数据库之中。

3. 事务的隔离级别有哪些？MySQL的默认隔离级别是什么？

事务的隔离级别有四种，分别是：读未提交（Read Uncommitted）、读已提交（Read Committed）、可重复读（Repeatable Read）、串行化（Serializable）。

读未提交隔离级别：只限制了两个数据不能同时修改，但是修改数据的时候，即使事务未提交，都是可以被别的事务读取到的，这级别的事务隔离有脏读、重复读、幻读的问题；
读已提交隔离级别：当前事务只能读取到其他事务提交的数据，所以这种事务的隔离级别解决了脏读问题，但还是会存在重复读、幻读问题；
可重复读： 可重复读隔离级别，限制了读取数据的时候，不可以进行修改，所以解决了重复读的问题，但是读取范围数据的时候，是可以插入数据，所以还会存在幻读问题；
串行化： 事务最高的隔离级别，在该级别下，所有事务都是进行串行化顺序执行的。可以避免脏读、不可重复读与幻读所有并发问题。但是这种事务隔离级别下，事务执行很耗性能。

Mysql默认的事务隔离级别是可重复读(RR)。

4. Mysql为什么选择RR作为默认隔离级别？

我们知道Mysql有四种数据库隔离级别，分别是读未提交、读已提交、可重复读、串行化。而读未提交隔离级别太低了，会有脏读问题，串行化隔离级别太高了，会影响并发读。那么就剩下读已提交（RC）和可重复读（RR）了。

那么，Mysql为什么会选择RR作为默认隔离级别呢？

我们的MySQL数据库一般都是集群部署的，会有主库、从库。主库负责写，从库负责读。主库写入之后，会进行主从复制，把数据同步到从库。

从库是在主库拿到bin log日志，并执行bin log，从而保证从库与主库的数据一致性。

实际上，bin log有三种格式，分别是statement，row和mixed。如果是statement格式，bin log记录的是SQL的原文。Mysql早些时候，bin log日志格式只有statement这种，在RC的隔离级别，可能出现数据不一致的问题。

MySQL官网上还记录了这个bug。

我们可以复现这个bug，假设有表结构如下：

   CREATE TABLE t (
      a int(11) DEFAULT NULL,
      b int(11) DEFAULT NULL,
      KEY a (a)
    ) ENGINE=InnoDB DEFAULT CHARSET=latin1;

插入两条数据

insert into t values(666,2),(233,1);

执行以下这两个事务：

执行完之后，因为事务的隔离级别是RC，所以事务A在更新时，会对 b=2加行级锁，所以执行结果为(888,2)，事务B在执行时，不受行级锁的影响，两条数据变为(888,2),(233,2)。

在RC隔离级别下，我们再来看下bin log日志。当两个事务执行完后，会先记录事务B的bin log日志，因为它最先提交，然后才生成事务A的bin log日志。当bin log日志格式是statement，binlog记录的就是原文，也就是先记录update t set b=2 where b = 1;，然后才记录update t set a=888 where b=2。

酱紫的话，当主库把binlog同步到从库，执行SQL回放后，数据库中的数据就变成了(888,2)和(888,2)，主数据库和从数据库数据不一致啦。而在RR（可重复读的数据库隔离级别）下，因为会有间隙锁的存在，这种情况就不会发生，因此，Mysql默认选择RR作为隔离级别。

5. 很多大厂为什么选择RC数据库隔离级别？

互联网大厂和一些传统企业，最明显的特点就是高并发。那么大厂就更倾向提高系统的并发读。

RC隔离级别，并发度是会比RR更好的，为什么呢？

因为RC隔离级别，加锁过程中，只需要对修改的记录加行锁。而RR隔离级别，还需要加Gap Lock和Next-Key Lock，即RR隔离级别下，出现死锁的概率大很多。并且，RC还支持半一致读，可以大大的减少了更新语句时行锁的冲突；如果对于不满足更新条件的记录，就可以提前释放锁，提升并发度。

一致性读:又称为快照读。快照即当前行数据之前的历史版本。快照读就是使用快照信息显示基于某个时间点的查询结果，而不考虑与此同时运行的其他事务所执行的更改。

当前读: 当前读的规则，就是要能读到所有已经提交的记录的最新值。

半一致性读：一条update语句，如果 where 条件匹配到的记录已经加锁，那么InnoDB会返回记录最近提交的版本，由MySQL上层判断此是否需要真的加锁。

6. 并发场景，数据库存在哪些一致性问题？

脏读：如果一个事务读取到了另一个未提交事务修改过的数据，我们就称发生了脏读现象。
不可重复读：同一个事务内，前后多次读取，读取到的数据内容不一致
幻读：如果一个事务先根据某些搜索条件查询出一些记录，在该事务未提交时，另一个事务写入了一些符合那些搜索条件的记录（如insert、delete、update），就意味着发生了幻读。
丢失更新：事务A和事务B都对同一个数据进行修改，事务A先修改，事务B随后修改，事务B的修改覆盖了事务A的修改。

7. 四大隔离级别，都会存在哪些并发问题呢？

隔离级别	脏读	不可重复读	幻读
读未提交（RU）	√	√	√
读已提交（RC）	×	√	√
可重复读（RR）	×	×	√
串行化（Serializable）	×	×	×

在RU隔离级别下，可能发生脏读、不可重复读、幻读现象。
在RC隔离级别下，可能发生不可重复读、幻读现象。
在RR隔离级别下，可能发生幻读现象。
在Serializable隔离级别，会强制事务串行执行，不会存在脏读、不可重复读、幻读现象。

8. MySQL的隔离级别是如何实现的？

MySQL的隔离级别是通过MVCC和锁机制来实现的。

RU隔离级别最低，没有加锁，存在脏读问题。事务读不加锁，不阻塞其他事务的读和写
RC和RR隔离级别可以通过MVCC来实现。
串行化是通过锁机制实现。读加共享锁，写加排他锁，读写互斥。如果有未提交的事务正在修改某些行，所有select这些行的语句都会阻塞。

9. 什么是MVCC，它的底层原理？

MVCC，即Multi-Version Concurrency Control(多版本并发控制)。它是一种并发控制的方法，一般在数据库管理系统中，实现对数据库的并发访问.

通俗的讲，数据库中同时存在多个版本的数据，并不是整个数据库的多个版本，而是某一条记录的多个版本同时存在，在某个事务对其进行操作的时候，需要查看这一条记录的隐藏列事务版本id，对比事务id并根据事物隔离级别去判断读取哪个版本的数据。

要了解MVCC的底层原理，需要回顾很多相关知识点，我们按以下小提纲，来分析哈：

什么是快照读和当前读
隐式字段
什么是Undo Log
什么是快照版本链
事务版本号
什么是Read View
查询一条记录，基于MVCC，是怎样流程
基于MVCC，RC隔离级别，存在不可重复读问题的分析

9.1 什么是快照读和当前读

快照读：读取的是记录数据的可见版本（有旧的版本）。不加锁,普通的select语句都是快照读。
当前读：读取的是记录数据的最新版本，显式加锁的都是当前读。

快照读是MVCC实现的基础。

9.2 隐式字段

对于InnoDB存储引擎，每一行记录都有两个隐藏列trx_id、roll_pointer，如果表中没有主键和非NULL唯一键时，则还会有第三个隐藏的主键列row_id。

9.3 什么是Undo Log

undo log，回滚日志，用于记录数据被修改前的信息。在表记录修改之前，会先把数据拷贝到undo log里，如果事务回滚，即可以通过undo log来还原数据。

可以这样认为，当delete一条记录时，undo log中会记录一条对应的insert记录，当update一条记录时，它记录一条对应相反的update记录。

undo log有什么用途呢？

事务回滚时，保证原子性和一致性。
用于MVCC快照读。

9.4 快照版本链

多个事务并行操作某一行数据时，不同事务对该行数据的修改会产生多个版本，然后通过回滚指针（roll_pointer），连成一个链表，这个链表就称为版本链。如下：

9.5 事务版本号

事务每次开启前，都会从数据库获得一个自增长的事务ID，可以从事务ID（trx_id）判断事务的执行先后顺序。这就是事务版本号。

9.6 什么是Read View

Read View是什么呢？它就是事务执行SQL语句时，产生的读视图。实际上在innodb中，每个SQL语句执行前都会得到一个Read View。它主要是用来做可见性判断的，即判断当前事务可见哪个版本的数据~

在Read View中，有这几个重要的属性。

m_ids:当前系统中，那些未提交的读写事务ID列表。
min_limit_id:表示在生成Read View时，当前系统中活跃的读写事务中最小的事务id，即m_ids中的最小值。
max_limit_id:表示生成Read View时，系统中应该分配给下一个事务的id值。
creator_trx_id: 创建当前Read View的事务ID

Read view 匹配条件规则（很重要）如下：

如果数据事务ID trx_id < min_limit_id，表明生成该版本的事务在生成Read View前，已经提交(因为事务ID是递增的)，所以该版本可以被当前事务访问。
如果trx_id>= max_limit_id，表明生成该版本的事务在生成Read View后才生成，所以该版本不可以被当前事务访问。
如果 min_limit_id =<trx_id< max_limit_id,需腰分3种情况讨论

（1）.如果m_ids包含trx_id,则代表Read View生成时刻，这个事务还未提交，但是如果数据的trx_id等于creator_trx_id的话，表明数据是自己生成的，因此是可见的。

（2）如果m_ids包含trx_id，并且trx_id不等于creator_trx_id，则Read View生成时，事务未提交，并且不是自己生产的，所以当前事务也是看不见的；

（3）.如果m_ids不包含trx_id，则说明你这个事务在Read View生

成之前就已经提交了，修改的结果，当前事务是能看见的。

9.7 查询一条记录，基于MVCC，是怎样的流程

获取事务自己的版本号，即事务ID（trx_id）
获取Read View
查询得到的数据，然后Read View中的事务版本号进行比较。
如果不符合Read View的可见性规则，即就需要Undo log中历史快照;
最后返回符合规则的数据

InnoDB 实现MVCC，是通过Read View+ Undo Log实现的，Undo Log保存了历史快照，Read View可见性规则帮助判断当前版本的数据是否可见。

9.8 基于MVCC，RC隔离级别，存在不可重复读问题的分析

为了加深大家对MVCC的理解，我们来分析一个例子吧：比如RC隔离级别，存在不可重复读问题，我们来分析这个过程哈。

先创建core_user表，插入一条初始化数据,如下：

隔离级别设置为读已提交（RC），事务A和事务B同时对core_user表进行查询和修改操作。

事务A: select * fom core_user where id=1
事务B: update core_user set name =”曹操”

最后事务A查询到的结果是，name=曹操的记录，我们基于MVCC，来分析一下执行流程：

(1) A开启事务，首先得到一个事务ID为100 (2) B开启事务，得到事务ID为101 (3) 事务A生成一个Read View，read view对应的值如下

然后回到版本链：开始从版本链中挑选可见的记录：

由图可以看出，最新版本的列name的内容是孙权，该版本的trx_id值为100。判断read view可见性规则校验：

min_limit_id(100)=<trx_id（100）<102;
creator_trx_id = trx_id =100;

由此可得，trx_id=100的这个记录，当前事务是可见的。所以查到是name为孙权的记录。

(4) 事务B进行修改操作，把名字改为曹操。把原数据拷贝到undo log,然后对数据进行修改，标记事务ID和上一个数据版本在undo log的地址。

(5) 提交事务 (6) 事务A再次执行查询操作，新生成一个Read View，Read View对应的值如下

然后再次回到版本链：从版本链中挑选可见的记录：

从图可得，最新版本的列name的内容是曹操，该版本的trx_id值为101。判断Read View可见性规则校验：

min_limit_id(100)=<trx_id（101）<max_limit_id（102);
但是,trx_id=101，不属于m_ids集合

因此，trx_id=101这个记录，对于当前事务是可见的。所以SQL查询到的是name为曹操的记录。

综上所述，在读已提交（RC）隔离级别下，同一个事务里，两个相同的查询，读取同一条记录（id=1），却返回了不同的数据（第一次查出来是孙权，第二次查出来是曹操那条记录），因此RC隔离级别，存在不可重复读并发问题。

而在RR隔离级别，一个事务里，每一次查询，都只会获取一次read view，都是副本共用的，从而保证每次查询的数据都是一样的，因此它是解决了不可重复读的并发问题的哈。大家可以自己手动去分析以下，这就是MVCC原理所在。

10. 如何处理大事务和长事务？请给出一些处理方法。

处理大事务和长事务是数据库设计和优化中非常重要的一部分，以下是一些常用的处理方法：

大事务拆分为小事务：将大事务拆分为多个小事务，减少每个事务操作的数据量，可以减少锁竞争和死锁的风险，提高并发性能。
优化查询语句：对于长事务中的查询操作，可以通过优化查询语句来提高查询性能，如添加索引、优化SQL结构等。
避免长时间占用锁：长事务会占用锁资源，导致其他事务无法访问相应的数据，因此需要尽可能缩短事务的执行时间，避免长时间占用锁。
避免长时间的事务等待：长事务可能会导致其他事务的等待时间过长，影响系统的性能和可用性，因此需要尽可能缩短事务的执行时间，避免长时间的事务等待。
优化事务日志：长事务会占用大量的事务日志，导致数据库性能下降，因此需要通过优化事务日志的写入和刷盘策略来提高性能。
使用定时任务：长时间运行的事务可以通过定时任务来定期执行，以避免长时间占用资源。
适当增加硬件资源：如果以上方法不能解决问题，可以适当增加硬件资源，如增加内存、CPU、存储等，以提高系统性能。

11. 如何优化 MySQL 事务的性能？请列举一些优化方法。

MySQL 事务性能优化是提高数据库性能的关键之一，以下是一些常用的优化方法：

选择合适的存储引擎：不同的存储引擎具有不同的特性和性能，因此需要根据具体的业务需求选择合适的存储引擎，如 MyISAM、InnoDB、Memory 等。
使用合适的索引：合理的索引可以提高查询和更新操作的效率，因此需要根据实际业务情况添加适当的索引，避免全表扫描。
避免不必要的锁定：不必要的锁定会降低并发性能，因此需要避免不必要的锁定，如优化查询语句、使用乐观锁等。
选择合适的事务隔离级别：不同的事务隔离级别具有不同的特性和性能影响，因此需要根据实际业务情况选择合适的事务隔离级别。
减少事务的范围：尽量减小事务的范围，将大事务拆分为多个小事务，

可以减少锁竞争和死锁的风险，提高并发性能。
使用合适的事务提交方式：对于不需要回滚的事务，可以使用自动提交方式，减少提交操作的次数，提高性能。
避免长事务：长时间运行的事务会占用大量的资源，影响并发性能，因此需要尽可能缩短事务的执行时间，避免长时间的事务等待。
优化数据库服务器的硬件和配置：优化数据库服务器的硬件和配置可以提高数据库性能，如增加内存、优化磁盘性能、调整缓存大小等。
使用分布式数据库：对于高并发的场景，可以使用分布式数据库架构，将数据分布到多个数据库节点上，提高并发性能。

当然，这些方法可能并不适用于所有业务场景，需要根据具体情况进行选择和调整。

12. Innodb的事务实现的基本原理

InnoDB 是 MySQL 中一种常用的存储引擎，支持事务和行级锁等高级特性。以下是 InnoDB 实现事务的基本原理：

InnoDB 中，每个事务都拥有一个唯一的事务 ID（transaction ID），通过该 ID 来区分不同的事务。
InnoDB 使用 MVCC（多版本并发控制）来实现事务的隔离性，每次修改会生成一个新版本，查询时只能看到在查询开始之前就已经提交的版本，这样可以避免读取到脏数据。
在执行事务中的更新操作时，InnoDB 会根据需要对相关的数据行加锁，以保证事务的原子性和一致性。InnoDB 中的行级锁是通过在索引节点上加锁来实现的，因此对于相同的数据行，不同的事务可以分别通过不同的索引来访问和修改数据。
InnoDB 中的事务支持 ACID 特性，即原子性、一致性、隔离性和持久性。InnoDB 通过 redo log 和 undo log 来保证事务的原子性和持久性，其中 redo log 记录了事务的修改操作，而 undo log 则记录了事务的回滚操作。当系统崩溃或者发生其他故障时，InnoDB 可以通过 redo log 和 undo log 来恢复数据到事务提交前的状态，以保证数据的一致性和持久性。
InnoDB 中的事务隔离级别包括读未提交、读已提交、可重复读和串行化。默认的隔离级别是可重复读，使用锁和 MVCC 机制来实现。在高并发的情况下，如果锁的粒度过大或者锁的竞争过激，可能会导致性能瓶颈或者死锁问题，因此需要针对具体场景进行优化。