关于mysql:理解完这些基本上能解决面试中MySql的事务问题

越致力，越侥幸，
本文已珍藏在GitHub中JavaCommunity, 外面有面试分享、源码剖析系列文章，欢送珍藏，点赞
https://github.com/Ccww-lx/Ja...

前言

在面试中，基本上都会问到对于数据库的事务问题，如果啥都不会或者只答复到外表的上知识点的话，那面试基本上是没戏了，为了能顺利通过面试，那MySql的事务问题就须要理解，所以就依据网上的材料总结一版Mysql事务的知识点，坚固一下事务的常识。

事务

事务是指逻辑上的一组操作，要么都执行，要么都不执行,

事务的个性（ACID）

原子性(Atomicity)：事务是不可分割的工作单元，要么都胜利，要么都失败，如果事务中一个sql语句执行失败，则已执行的语句也必须回滚，数据库退回到事务前的状态。
一致性(Consistency)：事务不能毁坏数据的完整性和业务的一致性。例如在银行转账时，不论事务胜利还是失败，单方钱的总额不变
隔离性(Isolation)：一个事务所操作的数据在提交之前，对其余事务的可见性设定（个别是不可见）
持久性(Durability)：事务提交之后，所做的批改就会永恒保留，不会因为系统故障导致数据失落

严格来说，只有同时满足数据库的事务ACID个性能力算一个残缺的事务，但事实中实现可能真正满足的残缺的事务个性少之又少，然而在实现中也必须尽量达到事务要求的个性。

那么事务ACID个性具体怎么实现的呢？咱们来剖析看看，首先先看看事务的个性。

原子性(`Atomicity`)

首先咱们来看看事务的原子性个性，看看其如何实现的？

原子性(Atomicity)：事务是不可分割的工作单元，要么都胜利，要么都失败，如果事务中一个sql语句执行失败，则已执行的语句也必须回滚，数据库退回到事务前的状态

原子性(Atomicity)的实现离不开 MySQL的事务日志 undo log日志类型，当事务须要回滚的时候须要将数据库状态回滚到事务开始前，即须要撤销所有曾经胜利执行的sql语句。那么undo log起了关键性作用：

当事务对数据库进行批改时，InnoDB会生成对应的undo log；如果事务执行失败或调用了rollback，导致事务须要回滚，便能够利用undo log中的信息将数据回滚到批改之前的样子。

那么undo log是什么呢？每个数据变更操作是怎么被记录下来的呢？

undo log（回滚日志）

undo log (回滚日志)：是采纳段(segment)的形式来记录的，每个undo操作在记录的时候占用一个undo log segment。为什么会在数据更改操作的时候，记录了绝对应的undo log呢？其目标在于：

为了保证数据的原子性，记录事务产生之前的一个版本，用于回滚，
通过mvcc+undo log实现innodb事务可反复读和读取已提交隔离级别。

其中，undo log分为：

insert undo log ： insert操作中产生的undo log，
update undo log：对delete 和update操作产生的undo log

数据更改的undo log怎么记录的呢？

因为insert操作的记录，只对事务自身可见，对其余事务不可见。故该undo log能够在事务提交后间接删除，不须要进行purge操作，

而Delete操作在事务中实际上并不是真正的删除掉数据行，而是一种Delete Mark操作，在记录上标识Delete_Bit，而不删除记录。是一种"假删除",只是做了个标记，真正的删除工作须要后盾purge线程去实现。

update分为两种状况：update的列是否是主键列。

如果不是主键列，在undo log中间接反向记录是如何update的。即update是间接进行的。
如果是主键列，update分两部执行：先删除该行，再插入一行指标行。

与insert undo log 不同的，update undo log日志，当事务提交的时候，innodb不会立刻删除undo log，会将该事务对应的undo log放入到删除列表中，将来通过purge线程来删除。

因为后续还可能会用到undo log，如隔离级别为repeatable read时，事务读取的都是开启事务时的最新提交行版本，只有该事务不完结，该行版本就不能删除（即undo log不能删除）,且undo log调配的页可重用缩小存储空间和晋升性能。

Note： purge线程两个次要作用是：清理undo页和革除page外面带有Delete_Bit标识的数据行。

接着咱们来看看事务的隔离性，看看事务有哪些隔离级别，而且事务并发中会产生什么问题。

隔离性(`Isolation`)

隔离性(Isolation)，是指事务外部的操作与其余事务是隔离的，并发执行的各个事务之间不能相互烦扰，一个事务所操作的数据在提交之前，对其余事务的可见性设定(个别是不可见)。

事务隔离级别

而且数据库为了在并发下无效保障读取数据正确性，数据库提供了四种事务隔离级别>，别离为：

读未提交(脏读)：容许读取尚未提交的数据，容许脏读
读已提交（ 不可反复读 ）：容许读取事务曾经提交的数据
可反复读（幻读）：在同一个事务内的查问后果都是和事务开始时刻查问统一的（ InnoDB默认级别）
串行化：所有事务一一顺次执行，每次读都须要取得表级共享锁，读写互相都会阻塞

其中，不同的隔离级别可能会存在在不同并发问题>，次要并发问题包含：

数据失落： 两个或多个事务操作雷同数据，基于最后选定的值更新该行时，因为每个事务都不晓得其余事务的存在，就会产生失落更新问题——最初的更新笼罩了其余事务所做的更新
脏读：读到了其余事务还未提交的数据，事务A读取了事务B更新的数据，而后B回滚操作，那么A读取到的数据是脏数据

不可反复读（重点是批改）：在一个事务中，先后进行两次雷同的读取，因为另一个事务批改了数据，导致前后两次后果的不统一，事务A屡次读取同一数据，事务B在事务A屡次读取的过程中，对数据作了更新并提交，导致事务A屡次读取同一数据时，后果不统一。

幻读（重点是新增、删除）： 在一个事务中，先后进行两次雷同的读取（个别是范畴查问），因为另一个事务新增或删除了数据，导致前后两次后果不统一

不可反复读和幻读的区别？
不可反复读和幻读最大的区别，就在于如何通过锁机制来解决他们产生的问题，
应用锁机制来实现这两种隔离级别，在可反复读中，雷同sql第一次读取到数据后就将这些数据加锁，其它事务无奈更新操作这些数据来实现可反复读了隔离。
但这种解决形式却无奈锁住insert的数据，因而会呈现当事务A先前读取了数据，事务B再insert数据提交，后果发现事务A就会发现莫名其妙多了些数据，这就是幻读，不能通过行锁来防止。

理解了并发问题后，来看看不同的隔离级别可能会存在在不同并发问题：

事务隔离级别	脏读	不可反复读	幻读
读未提交	是	是	是
不可反复读	否	是	是
可反复读	否	否	是
串行化	否	否	否

为了实现事务隔离，延长出了数据库锁。其中，innodb事务的隔离级别是由锁机制和MVCC（多版本并发管制）来实现的

那咱们来先看看锁的原理，怎么应用锁来实现事务隔离的呢？

锁机制

锁机制的根本工作原理，事务在批改数据之前，须要先取得相应的锁；取得锁之后，事务便能够批改数据；该事务操作期间，这部分数据是锁定的，其余事务如果须要批改数据，须要期待以后事务提交或回滚后开释锁，

MySQL次要分成三种类型（级别）的锁机制：

表级锁：最大颗粒度的锁机制，锁定资源争用的概率也会最高，并发度最低，但开销小，加锁快，不会呈现死锁，
行级锁：最大颗粒度的锁机制很小，产生锁定资源争用的概率也最小，可能给予应用程序尽可能大的并发解决能力而进步一些须要高并发利用零碎的整体性能，但开销大，加锁慢；会呈现死锁，
页级锁：开销和加锁工夫界于表锁和行锁之间；会呈现死锁；锁定粒度界于表锁和行锁之间，并发度个别

而且不同的存储引擎反对不同的的锁机制，次要剖析一下InnoDB锁。

InnoDB锁

InnoDB实现了以下两种类型的行锁

共享锁（S锁、行锁）：多个事务对同一数据行能够共享一把锁，只能读不能批改
排它锁（X锁、行锁）：一个事务获取一个数据行的排它锁，那么其余事务将不能再获取该行的锁（共享锁、排它锁），容许获取排他锁的事务更新数据

对于UPDATE,DELETE,INSERT操作， InnoDB会主动给波及及数据集加排他锁（Ｘ）；对于一般SELECT语句，InnoDB不会加任何锁,

而且因为InnoDB引擎容许行锁和表锁共存，实现多粒度锁机制，应用意向锁实现表锁机制，

动向共享锁（IS锁、表锁）：当事务筹备给数据行加共享锁时，会先给表加上一个动向共享锁。动向共享锁之间是兼容的
动向排它锁（IX锁、表锁）：当事务筹备给数据行加排它锁时，会先给表加上一个动向排它锁。动向排它锁之间是兼容的

意向锁(IS、IX)是InnoDB数据操作之前主动加的，不须要用户干涉。它的意义在于：当事务想去进行锁表时，能够先判断意向锁是否存在，存在时则可疾速返回该表不能启用表锁，否则就须要期待，

其中，四种锁的兼容性如下

以后锁模式/是否兼容/申请锁模式	X	IX	S	IS
X	抵触	抵触	抵触	抵触
IX	抵触	兼容	抵触	兼容
S	抵触	抵触	兼容	兼容
IS	抵触	兼容	兼容	兼容

如果一个事务申请的锁模式与以后的锁兼容，InnoDB就申请的锁授予该事务；反之，如果两者两者不兼容，该事务就要期待锁开释。

InnoDB行锁

InnoDB的行锁是通过给索引上的索引项加锁来实现的。只有通过索引检索数据，能力应用行锁，否则将应用表锁（锁住索引的所有记录）

临键锁(next-key)，能够避免幻读。依据索引，划分为一个个左开右闭的区间。当进行范畴查问的时候，若命中索引且可能检索到数据，则锁住记录所在的区间和它的下一个区间,

其实，临键锁(Next-Key)=记录锁(Record Locks)+间隙锁(Gap Locks)，

当咱们用范畴条件检索数据而不是相等条件检索数据，并申请共享或排他锁时，InnoDB会给合乎范畴条件的已有数据记录的索引项加锁；对于键值在条件范畴内但并不存在的记录，叫做间隙(GAP)。
当应用惟一索引，且记录存在的精准查问时，应用Record Locks记录锁

具体的应用体现在哪里呢？如下图所示：

范畴查问，记录存在

当记录不存在（不论是等值查问，还是范畴查问）时，next-key将进化成Gap Lock（间隙锁）

当条件是精准匹配（即为等值查问时）且记录存在时，并且是惟一索引，临键锁(Next-Key)进化成Record Lock（记录锁）

当条件是精准匹配（即为等值查问时）且记录存在，但不是惟一索引时，临键锁(Next-Key)会有精准值的数据会减少Record Lock（记录锁）和精准值前后的区间的数据会减少Gap Lock（间隙锁)。

如何应用锁解决并发问题

利用锁解决脏读、不可反复读、幻读

X锁解决脏读
S锁解决不可反复读
临键锁解决幻读

`Multiversion concurrency control` (`MVCC` 多版本并发管制)

InnoDB的MVCC是通过在每行记录前面保留两个暗藏的列来实现的，一个保留了行的事务ID（事务ID就会递增），一个保留了行的回滚段的指针 。

每开始一个新的事务，都会主动递增产生一个新的事务id。事务开始时刻的会把事务id放到以后事务影响的行事务id中，而DB_ROLL_PTR示意指向该行回滚段的指针，该行记录上所有版本数据，在undo中都通过链表模式组织，该值理论指向undo中该行的历史记录链表，

在并发拜访数据库时，对正在事务中的数据做MVCC多版本的治理，以防止写操作阻塞读操作，并且会通过比拟版本解决幻读。

而且MVCC只在REPEATABLE READ和READ COMMITIED两个隔离级别下才会工作，其中，MVCC实现本质就是保留数据在某个工夫点的快照来实现的。 那哪些操作是快照读？

快照读和以后读

快照读，innodb快照读，数据的读取将由 cache(本来数据) + undo(事务批改前的数据) 两局部组成

一般的select，比方 select * from table where ?;

以后读，SQL读取的数据是最新版本。通过锁机制来保障读取的数据无奈通过其余事务进行批改

UPDATE
DELETE
INSERT
SELECT … LOCK IN SHARE MODE
SELECT … FOR UPDATE
其中以后读中，只有SELECT … LOCK IN SHARE MODE对读取记录加S锁 (共享锁)外，其余的操作，都加的是X锁 (排它锁)。

那么在RR隔离级别下，MVCC具体是如何操作的。

RR隔离级别下，MVCC具体操作

SELECT操作，InnoDB遵循当前两个规定执行：

InnoDB只查找版本早于以后事务版本的数据行（即行的事务编号小于或等于以后事务的事务编号），这样能够确保事务读取的行，要么是在事务开始前曾经存在的，要么是事务本身插入或者批改过的记录。
行的删除版本要么未定义,读取到事务开始之前状态的版本>,这能够确保事务读取到的行，在事务开始之前未被删除.只有同时满足的两者的记录，能力返回作为查问后果.

INSERT：InnoDB为新插入的每一行保留以后事务编号作为行版本号。

DELETE：InnoDB为删除的每一行保留以后事务编号作为行删除标识。

UPDATE：InnoDB为插入一行新记录，保留以后事务编号作为行版本号，同时保留以后事务编号到原来的行作为行删除标识>。

保留这两个额定零碎版本号，使大多数读操作都能够不必加锁。这样设计使得读数据操作很简略，性能很好，并且也能保障只会读取到符合标准的行，不足之处是每行记录都须要额定的存储空间，须要做更多的行查看工作，以及一些额定的保护工作。

剖析完了原子性和隔离性，咱们持续看看事务的持久性。

持久性(`Durability`)

持久性(Durability)：事务提交之后，所做的批改就会永恒保留，不会因为系统故障导致数据失落，

而且其实现的关键在于redo log，在执行SQL时会保留已执行的SQL语句到一个指定的Log文件，当执行recovery时从新执行redo log记录的SQL操作。

那么redo log如何实现的呢？

redo log

当向数据库写入数据时，执行过程会首先写入Buffer Pool，Buffer Pool中批改的数据会定期刷新到磁盘中（这一过程称为刷脏），这整一过程称为redo log。redo log 分为：

Buffer Pool内存中的日志缓冲(redo log buffer)，该局部日志是易失性的；
磁盘上的重做日志文件(redo log file)，该局部日志是长久的。

Buffer Pool的应用能够大大提高了读写数据的效率，然而也带了新的问题：如果MySQL宕机，而此时Buffer Pool中批改的数据在内存还没有刷新到磁盘，就会导致数据的失落，事务的持久性无奈保障。

为了确保事务的持久性，在当事务提交时，会调用fsync接口对redo log进行刷盘, （即redo log buffer写日志到磁盘的redo log file中）,刷新频率由 innodb_flush_log_at_trx_commit变量来管制的：

0 ：每秒刷新写入到磁盘中的，当零碎解体，会失落1秒钟的数据；
1：事务每次提交都写入磁盘；
2：每秒刷新写入到磁盘中的，但跟0是有区别的。

redo log有更加具体的解读，后续有工夫再补上，到当初为止，曾经将事务三个个性都了解了，那事务一致性呢？

一致性(`Consistency`)

一致性(Consistency)：事务不能毁坏数据的完整性和业务的一致性：

数据的完整性：实体完整性、列完整性（如字段的类型、大小、长度要符合要求）、外键束缚等
业务的一致性：例如在银行转账时，不论事务胜利还是失败，单方钱的总额不变。

那是如何保证数据一致性的？

其实数据一致性是通过事务的原子性、持久性和隔离性来保障的

原子性：语句要么全执行，要么全不执行，是事务最外围的个性，事务自身就是以原子性来定义的；实现次要基于undo log
持久性：保障事务提交后不会因为宕机等起因导致数据失落；实现次要基于redo log
隔离性：保障事务执行尽可能不受其余事务影响；InnoDB默认的隔离级别是RR，RR的实现次要基于锁机制（蕴含next-key lock）、MVCC（包含数据的暗藏列、基于undo log的版本链、ReadView）

总结

其中要同时满足ACID个性，这样的事务少之又少。理论中很多例子都只是满足一些个性，比方：

MySQL的NDB Cluster事务不满足持久性和隔离性；
InnoDB默认事务隔离级别是可反复读，不满足隔离性；
Oracle默认的事务隔离级别为READ COMMITTED，不满足隔离性

所以咱们只能应用这个四个维度的个性去掂量事务的操作。

谢谢各位点赞，没点赞的点个赞反对反对
最初，微信搜《Ccww技术博客》观看更多文章，也欢送关注一波。

前言

事务