五分钟！快速读懂数据库原理

一、事务

事务指的是满足ACID特性的一组操作，可以通过Commit提交一个事务，也可以使用Rollback进行回滚。

事务被视为不可分割的最小单元，事务的所有操作要么全部提交成功，要么全部失败回滚。

回滚可以用回滚日志来实现，回滚日志记录着事务所执行的修改操作，在回滚时反向执行这些修改操作即可。

数据库在事务执行前后都保持一致性状态。在一致性状态下，所有事务对一个数据的读取结果都是相同的。

强一致性、弱一致性、最终一致性：*对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强一致性；如果能容忍后续的部分或者全部访问不到，则是弱一致性**；如果经过一段时间后要求能访问到更新后的数据，则是最终一致性。*

一个事务所做的修改在最终提交以前，对其它事务是不可见的。

一旦事务提交，则其所做的修改将会永远保存到数据库中。即使系统发生崩溃，事务执行的结果也不能丢失。

SQLServer中使用**了WAL（Write-AheadLogging，预写日志）**技术来保证事务日志的ACID特性，在数据写入到数据库之前，先写入到日志，再将日志记录变更到存储器中。

undo日志用于记录事务开始前的状态，用于事务失败时的回滚操作；redo日志记录事务执行后的状态，用来恢复未写入datafile的已成功事务更新的数据。例如某一事务的事务序号为T1，其对数据X进行修改，设X的原值是5，修改后的值为15，那么Undo日志为，Redo日志为。

梳理下事务执行的各个阶段：

innodb_flush_log_at_trx_commit=1标识：每次事务提交时，将存储引擎logbuffer中的redo日志写入到logfile，并调用文件系统的sync操作，将日志刷新到磁盘。

因为databuffer中的数据会在合适的时间由存储引擎写入到datafile，如果在写入之前，数据库宕机了，根据落盘的redo日志，完全可以将事务更改的数据恢复。这种先持久化日志的策略就叫做WriteAheadLog。参考数据库事物如何保证。

事务的ACID特性概念简单，但不是很好理解，主要是因为这几个特性不是一种平级关系：

MySQL默认采用自动提交模式。也就是说，如果不显式使用STARTTRANSACTION语句来开始一个事务(使用COMMIT来提交)，那么每个查询都会被当做一个事务自动提交。

在并发环境下，事务的隔离性很难保证，因此会出现很多并发一致性问题。

T1和T2两个事务都对一个数据进行修改，T1先修改，T2随后修改，T2的修改覆盖了T1的修改。

考虑飞机订票系统中的一个活动序列:

结果明明卖出两张机票，数据库中机票余额只减少1。

T1修改一个数据，T2随后读取这个数据。如果T1撤销了这次修改，那么T2读取的数据是脏数据。即脏读是指读取了事务回滚前的脏数据。

T2读取一个数据，T1对该数据做了修改。如果T2再次读取这个数据，此时读取的结果和第一次读取的结果不同。

也就是说，当前事务先进行了一次数据读取，然后再次读取到的数据是别的事务修改成功的数据，导致两次读取到的数据不匹配。

T1读取某个范围的数据，T2在这个范围内插入新的数据，T1再次读取这个范围的数据，此时读取的结果和和第一次读取的结果不同。

或者用更通俗地说，事务A首先根据条件索引得到N条数据，然后事务B改变了这N条数据之外的M条或者增添了M条符合事务A搜索条件的数据，导致事务A再次搜索发现有N+M条数据了，就产生了幻读。

也就是说，当前事务读第一次取到的数据比后来读取到数据条目少。

幻读和不可重复读的区别：幻读是读到之前没有出现过的数据，不可重复读是同一条数据两次读的结果不一样。不可重复读针对的是update或delete，幻读针对的insert。

产生并发不一致性问题主要原因是破坏了事务的隔离性，解决方法是通过并发控制来保证隔离性。并发控制可以通过封锁来实现，但是封锁操作需要用户自己控制，相当复杂。数据库管理系统提供了事务的隔离级别，让用户以一种更轻松的方式处理并发一致性问题。

MySQL中提供了两种封锁粒度：行级锁以及表级锁。

应该尽量只锁定需要修改的那部分数据，而不是所有的资源。锁定的数据量越少，发生锁争用的可能就越小，系统的并发程度就越高。

但是加锁需要消耗资源，锁的各种操作（包括获取锁、释放锁、以及检查锁状态）都会增加系统开销。因此封锁粒度越小，系统开销就越大。

在选择封锁粒度时，需要在锁开销和并发程度之间做一个权衡。

这里的读写锁是说行级锁。

有以下两个规定：

锁的兼容关系如下：

使用意向锁（IntentionLocks）可以更容易地支持多粒度封锁。

在存在行级锁和表级锁的情况下，事务T想要对表A加X锁，就需要先检测是否有其它事务对表A或者表A中的任意一行加了锁，那么就需要对表A的每一行都检测一次，这是非常耗时的。

意向锁在原来的X/S锁之上引入了IX/IS，IX/IS都是表锁，用来表示一个事务想要在表中的某个数据行上加X锁或S锁。有以下两个规定：

通过引入意向锁，事务T想要对表A加X锁，只需要先检测是否有其它事务对表A加了X/IX/S/IS锁，如果加了就表示有其它事务正在使用这个表或者表中某一行的锁，因此事务T加X锁失败。

各种锁的兼容关系如下：

解释如下：

事务T要修改数据A时必须加X锁，直到T结束才释放锁。

可以解决丢失修改问题，因为不能同时有两个事务对同一个数据进行修改，那么事务的修改就不会被覆盖。

在一级的基础上，要求读取数据A时必须加S锁，读取完马上释放S锁。

可以解决读脏数据问题，因为如果一个事务在对数据A进行修改，根据1级封锁协议，会加X锁，那么就不能再加S锁了，也就是不会读入数据。

在二级的基础上，要求读取数据A时必须加S锁，直到事务结束了才能释放S锁。

可以解决不可重复读的问题，因为读A时，其它事务不能对A加X锁，从而避免了在读的期间数据发生改变。

两段锁协议是指所有的事务必须分两个阶段对数据项加锁和解锁。即事务分两个阶段，第一个阶段是获得封锁。事务可以获得任何数据项上的任何类型的锁，但是不能释放；第二阶段是释放封锁，事务可以释放任何数据项上的任何类型的锁，但不能申请。（即在某段时间只能申请锁，在某段时间只能释放锁）

第一阶段是获得封锁的阶段，称为扩展阶段：其实也就是该阶段可以进入加锁操作，在对任何数据进行读操作之前要申请获得S锁，在进行写操作之前要申请并获得X锁，加锁不成功，则事务进入等待状态，直到加锁成功才继续执行。就是加锁后就不能解锁了。

第二阶段是释放封锁的阶段，称为收缩阶段：当事务释放一个封锁后，事务进入封锁阶段，在该阶段只能进行解锁而不能再进行加锁操作。

可串行化调度是指，通过并发控制，使得并发执行的事务结果与某个串行执行的事务结果相同。

事务遵循两段锁协议是保证可串行化调度的充分条件。例如以下操作满足两段锁协议，它是可串行化调度。

lock-x(A)lock-s(B)lock-s(C)unlock(A)unlock(C)unlock(B)

但不是必要条件，例如以下操作不满足两段锁协议，但是它还是可串行化调度。

lock-x(A)unlock(A)lock-s(B)unlock(B)lock-s(C)unlock(C)

MySQL的InnoDB存储引擎采用两段锁协议，会根据隔离级别在需要的时候自动加锁，并且所有的锁都是在同一时刻被释放，这被称为隐式锁定。

InnoDB也可以使用特定的语句进行显示锁定：

SELECTLOCKInSHAREMODE;SELECTFORUPDATE;

为了避免丢失更新、脏读、不可重复读和幻读，在标准SQL规范中，定义了4个事务隔离级别，不同的隔离级别对事务的处理不同。

只处理更新丢失。如果一个事务已经开始写数据，则不允许其他事务同时进行写操作，但允许其他事务读此行数据。事务中的修改，即使没有提交，对其它事务也是可见的。可通过“排他写锁”实现。

处理更新丢失、脏读。读取数据的事务允许其他事务继续访问改行数据，但是未提交的写事务将会禁止其他事务访问。也就是说一个事务只能读取已经提交的事务所做的修改。换句话说，一个事务所做的修改在提交之前对其它事务是不可见的。可通过“瞬间共享读锁”和“排他写锁”实现。

**处理更新丢失、脏读和不可重复读取。**多次读取同一范围的数据会返回第一次查询的快照，不会返回不同的数据行，但是可能发生幻读（PhantomRead）；

提供严格的事务隔离。对于同一行记录，“写”会加“写锁”，“读”会加“读锁”。当出现读写锁冲突的时候，后访问的事务必须等前一个事务执行完成，才能继续执行。解决了幻读问题。

参考：数据库四大特性及数据库隔离级别和数据库隔离级别。

隔离级别脏读可能性不可重复读可能性幻读可能性加锁读读未提交√√√×读提交×√√×可重复读××√×序列化×××√

多版本并发控制（Multi-VersionConcurrencyControl,MVCC）是MySQL的InnoDB存储引擎实现隔离级别的一种具体方式，用于实现提交读和可重复读这两种隔离级别。而未提交读隔离级别总是读取最新的数据行，无需使用MVCC。可串行化隔离级别需要对所有读取的行都加锁，单纯使用MVCC无法实现。

MVCC在大多数情况下代替了行锁。最早的数据库系统，只有读读之间可以并发，读写，写读，写写都要阻塞。引入多版本之后，只有写写之间相互阻塞，其他三种操作都可以并行，这样大幅度提高了InnoDB的并发度。

但是，使用MVCC每行记录都需要额外的存储空间，需要做更多的行维护和检查工作。

在不考虑redolog的情况下利用undolog工作的简化过程为：

Innodb通过undolog保存了已更改行的旧版本的信息的快照(read-view，数据库快照就可以理解为数据库某一时刻的照片，它记录了此时数据库的数据信息)。该日志通过回滚指针把一个数据行（Record）的所有快照连接起来。通过读取快照读取的信息都是过去的信息。

MVCC在每行记录后面都保存着两个隐藏的列，用来存储两个版本号：

具体如下：

列名长度(字节)作用DB_TRX_ID6插入或更新行的最后一个事务的事务标识符。（删除视为更新，将其标记为已删除）DB_ROLL_PTR7写入回滚段的撤消日志记录（若行已更新，则撤消日志记录包含在更新行之前重建行内容所需的信息）

以下实现过程针对可重复读隔离级别。

当开始新一个事务时，该事务的版本号肯定会大于当前所有数据行快照的创建版本号，理解这一点很关键。

InnoDB会根据两个条件来检查每行记录：

将当前系统版本号作为数据行快照的创建版本号。

将当前系统版本号作为数据行快照的删除版本号。

将当前系统版本号作为更新前的数据行快照的删除版本号，并将当前系统版本号作为更新后的数据行快照的创建版本号。可以理解为先执行DELETE后执行INSERT。

MySQL的InnoDB存储引擎默认事务隔离级别是RR(可重复读),是通过"行排他锁+MVCC"一起实现的，在innodb中的操作可以分为当前读(currentread)和快照读(snapshotread)。

使用MVCC读取的是快照中的数据，这样可以减少加锁所带来的开销。简单的select操作(当然不包括selectlockinsharemode,selectforupdate)是快照读。

select*fromtable;

读取的是最新的数据，需要加锁。以下第一个语句需要加S锁，其它都需要加X锁。

select*fromtablewhere?lockinsharemode;加写锁insert;update;delete;

在RR级别下，快照读是通过MVVC(多版本控制)和undolog来实现的，当前读是通过加recordlock(记录锁)和gaplock(间隙锁)来实现的。

innodb在快照读的情况下并没有真正的避免幻读,但是在当前读的情况下避免了不可重复读和幻读。

参考：『浅入浅出』MySQL和InnoDBMySQL-InnoDB-MVCC多版本并发控制MySQL中InnoDB的多版本并发控制(MVCC)轻松理解MYSQLMVCC实现机制数据库内核月报数据库内核月报

Next-KeyLock是MySQL的InnoDB存储引擎的一种锁实现。

MVCC不能解决幻读的问题，Next-KeyLock就是为了解决这个问题而存在的。在可重复读（REPEATABLEREAD）隔离级别下，使用MVCC+Next-KeyLock可以解决幻读问题。

InnoDB有三种行锁的算法：RecordLock、GapLock和Next-KeyLock，其中Next-KeyLock是前两者的结合。

锁定一个记录上的索引，而不是记录本身。

如果表没有设置索引，InnoDB会自动在主键上创建隐藏的聚簇索引，因此RecordLock依然可以使用。

锁定索引之间的间隙，但是不包含索引本身。例如当一个事务执行以下语句，其它事务就不能在中插入15。

SELECTcFROMtWHEREcBETWEEN10and20FORUPDATE;

它是RecordLock和GapLock的结合，不仅锁定一个记录上的索引，也锁定索引之间的间隙。例如一个索引包含以下值：10,11,13,and20，那么就需要锁定以下区间：

(negativeinfinity,10](10,11](11,13](13,20](20,positiveinfinity)

最后

刚整理2020年全套最新精品技术资料免费发给你！(原价最少8999元，超2000G！)

领取看看下面！！