Mysql核心框架

本文旨在梳理和理解 MySQL 的一些核心知识点，并结合常见面试题进行思考和总结。这些内容主要来源于我的个人学习与理解。

1. 事务

概念

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

那抹什么是ACID呢？

ACID

原子性（Atomicity）

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

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

一致性（Consistency）

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

我个人理解就是这个执行结果要合理，不能我转了你500，你拿到了1000这种状态。

隔离性（Isolation）

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

持久性（Durability）

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

系统发生崩溃可以用重做日志（·Redo Log·）进行恢复，从而实现持久性。与回滚日志记录数据的逻辑修改不同，重做日志记录的是数据页的物理修改。

举个例子:

例如，A向B转账500元，这个操作要么都成功，要么都失败，体现了原子性。转账过程中数据要保持一致，A扣除了500元，B必须增加500元。隔离性体现在A向B转账时，不受其他事务干扰。持久性体现在事务提交后，数据要被持久化存储。

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

只有满足一致性，事务的执行结果才是正确的。
在无并发的情况下，事务串行执行，隔离性一定能够满足。此时只要能满足原子性，就一定能满足一致性。
在并发的情况下，多个事务并行执行，事务不仅要满足原子性，还需要满足隔离性，才能满足一致性。
事务满足持久化是为了能应对系统崩溃的情况。

在这里插入图片描述

原子性和隔离性直接保证一致性，简介保证执行结果的正确。而一致性是觉得执行结果正确的直接因素。

持久性用于应对系统的崩溃，提高数据库的高可用性和鲁棒性。

2. 并发一致性问题

注意w为write操作,r为read操作

丢失修改

T1	T2
w a=10
	w a=20
r a=20
	r a=20

可以看到我们的T1线程和T2线程并发执行的时候T1丢失了原来a=10的操作痕迹，T2后提交覆盖了T1的提交，似乎T1没有执行w a=10的操作一样，这就是"丢失修改"。

读脏数据

T1	T2
r a=10
w a=20
	r a=20
rollback

T1,T2并发执行在前面都没问题，可是当T1rollback操作后数据库里面的值又变回了10，此时T2拿到并不是数据库真实的数据，如果拿着这个数据执行支付操作可想而知会给我们的系统造成多大的损失。

不可重复读

T1	T2
	r a=10
w a=20
	r a=20

其实不可重复读很好理解，就是在同一个事务中我进行两次读取操作结果获得值不相同，也可能会对我们的系统造成很大的困扰。

幻影读(幻读)

T1	T2
count(user_id) 1
	delete(user_object)
count(user_id) 0

幻读的出现场景主要在聚合函数统计时候出现的概率比较大一些。一个事务下的两次聚合操作竟然不相同，如果是在秒杀场景里面，可能就造成了超买超卖问题。

3. 封锁

锁的粒度

MySQL在粒度上分类的话分为行级锁、表级锁、页面锁

表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低。
行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。
页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般

从性能上看的话，锁的粒度越细，能够并发的线程数量就越多，性能就越高。反之则性能越低。所以从这个层面上考虑的行级锁的性能是高于标记锁的。

三种常用引擎的支持情况

InnoDB	MyISAM	MEMORY
行级锁和表级锁	支持表级锁	支持标记锁

从这也可以看出来InnoDB在锁的性能上是高于其他两个存储引擎的。

表级锁

基本的两大类表锁

ＭySQL的表锁有两种模式：表共享读锁（Table Read Lock）和表独占写锁（Table Write Lock）

表共享读锁（Table Read Lock）：不会阻塞其他用户对同一表的读请求，但会阻塞对同一表的写请求；
表独占写锁（Table Write Lock）：会阻塞其他用户对同一表的读和写操作；

当然有些存储引擎还支持意向锁，如我们大名鼎鼎的InnoDB。

是否阻塞	读锁	写锁
读锁	Y	N
写锁	N	N

tip：读读兼容，读写阻塞，写写阻塞

行级锁

基本的两大类行锁

共享锁（S 锁，Shared Lock）
- 允许多个事务同时读一行，但不能写。
排他锁（X 锁，Exclusive Lock）
- 一个事务获取排他锁后，别人既不能读也不能写（读是指加锁的读）。
- 常见在 UPDATE、DELETE、INSERT 操作里会自动加。

InnoDB 特有的“变种”行锁

为了处理复杂的并发场景，InnoDB 在基本 S/X 锁上又扩展出几种：

记录锁（Record Lock）
- 最常见的行锁，就是锁住某一条索引记录。
- 前提是查询必须用到索引，否则可能升级成表锁。
间隙锁（Gap Lock）
- 锁住某个范围的“间隙”，而不是已有的行。
- 用来防止“幻读”（别人插入新行导致范围查询结果变了）。
- 例如：
```
SELECT * FROM user WHERE age BETWEEN 20 AND 30 FOR UPDATE;
```
  FOR UPDATE → 给匹配行加排他锁。
  
  BETWEEN 20 AND 30 → 锁住这个范围的记录。
临键锁（Next-Key Lock）
- 记录锁 + 间隙锁的组合，锁住“某一条记录及其前面的间隙”。
- 这是 InnoDB 在 可重复读（RR） 隔离级别下的默认模式，主要就是为了防止幻读。

InnoDB默认情况下使用的就是行锁，如果要表锁的话必须显式加锁。

InnoDB与MyISAM的最大不同有两点：

一是支持事务（TRANSACTION）；
二是采用了行级锁。

行锁定是对索引记录的锁定。

SELECT c1 FROM t WHERE c1 = 10 FOR UPDATE;

防止任何其他事务插入，更新或删除t.c1值为10的行。

MySQL 的 UPDATE 在并发情况下，如果是 InnoDB 引擎，会通过行级排他锁避免同一行被多个事务同时修改。这也是Mysql层面上的解决超买超卖的一种手段捏。

行锁升级为表锁

行锁也有可能升级成表锁，具体的情况：

不适用索引的情况下加锁
使用普通索引的情况下加锁（tips:普通索引不限制值单纯建立b+树来加快查询速度，随便插,咱普遍说的索引一般是主键索引和唯一索引有非重复的需求)
范围性查询

总结行锁是建立在索引的基础上的，普通索引的数据重复率过高或导致索引失效，行锁升级为表锁

封锁的类型

读写锁

互斥锁（Exclusive），简写为 X 锁，又称写锁。
共享锁（Shared），简写为 S 锁，又称读锁。

有以下两个规定：

一个事务对数据对象 A 加了 X 锁，就可以对 A 进行读取和更新。加锁期间其它事务不能对 A 加任何锁。
一个事务对数据对象 A 加了 S 锁，可以对 A 进行读取操作，但是不能进行更新操作。加锁期间其它事务能对 A 加 S 锁，但是不能加 X 锁。

是否阻塞	读锁	写锁
读锁	Y	N
写锁	N	N

也就是上面行级锁里面的规定

意向锁

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

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

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

一个事务在获得某个数据行对象的 S 锁之前，必须先获得表的 IS 锁或者更强的锁；
一个事务在获得某个数据行对象的 X 锁之前，必须先获得表的 IX 锁。

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

4. 封锁协议

一共有三层封锁协议

一级封锁协议

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

T1	T2
lock-x a
w a=10	lock-x a
commit
unlock-x a
	get lock-x
	w a=20
	commit
	unlock-x a

可以看到，因为每次只有一个事务可以进行写操作，所以我们的事务修改就不会被覆盖

二级封锁协议

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

T1	T2
lock-x a
r a=10
w a=20	lock-s a
rollback
unlock-x a
	get lock-s
	r a=10
	unlock-s a

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

三级封锁协议

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

T1	T2
lock-x a
r a=10
r a=10	lock-x a
rollback
unlock-x a
	get lock-x
	w a=20
	commit
	unlock-x a

可以解决不可重复读的问题，因为读 A 时，其它事务不能对 A 加 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 也可以使用特定的语句进行显示锁定：

SELECT ... LOCK In SHARE MODE; #加读锁
SELECT ... FOR UPDATE;#加排他锁

5.隔离级别

未提交读（READ UNCOMMITTED）

事务中的修改，即使没有提交，对其它事务也是可见的。

提交读（READ COMMITTED）

一个事务只能读取已经提交的事务所做的修改。换句话说，一个事务所做的修改在提交之前对其它事务是不可见的。

因为在一个事务提交前的数据是对其他事务不可见的，所以在数据没有确定存入数据库前是不会被其他事务看见的，因此解决了数据被读到是修改后的值，但是另一个事务rollback修改，导致事务中读取到的数据与数据库中的数据不一致问题。即为解决了脏读问题。

可重复读（REPEATABLE READ）

保证在同一个事务中多次读取同一数据的结果是一样的。

可串行化（SERIALIZABLE）

强制事务串行执行，这样多个事务互不干扰，不会出现并发一致性问题。

该隔离级别需要加锁实现，因为要使用加锁机制保证同一时间只有一个事务执行，也就是保证事务串行执行。

隔离级别能解决的并发一致性问题

	脏读	不可重复读	幻影读
未提交读	×	×	×
提交读	√	×	×
可重复度	√	√	×
可串行化	√	√	√

6. MVCC

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

基本思想

在封锁一节中提到，加锁能解决多个事务同时执行时出现的并发一致性问题。在实际场景中读操作往往多于写操作，因此又引入了读写锁来避免不必要的加锁操作，例如读和读没有互斥关系。读写锁中读和写操作仍然是互斥的，而 MVCC 利用了多版本的思想，写操作更新最新的版本快照，而读操作去读旧版本快照，没有互斥关系，这一点和 CopyOnWrite读写分离 类似。

在 MVCC 中事务的修改操作（DELETE、INSERT、UPDATE）会为数据行新增一个版本快照。

脏读和不可重复读最根本的原因是事务读取到其它事务未提交的修改。在事务进行读取操作时，为了解决脏读和不可重复读问题，MVCC 规定只能读取已经提交的快照。当然一个事务可以读取自身未提交的快照，这不算是脏读。因为没有使用 START TRANSACTION 将上面的操作当成一个事务来执行，根据 MySQL 的 AUTOCOMMIT 机制，每个操作都会被当成一个事务来执行，所以上面的操作总共涉及到三个事务。快照中除了记录事务版本号 TRX_ID 和操作之外，还记录了一个 bit 的 DEL 字段，用于标记是否被删除。

Undo 日志

MVCC 的多版本指的是多个版本的快照，快照存储在 Undo 日志中，该日志通过回滚指针 ROLL_PTR 把一个数据行的所有快照连接起来。

在这里插入图片描述

例如在 MySQL 创建一个表 t，包含主键 id 和一个字段 x。我们先插入一个数据行，然后对该数据行执行两次更新操作。

INSERT INTO t(id, x) VALUES(1, "a");
UPDATE t SET x="b" WHERE id=1;
UPDATE t SET x="c" WHERE id=1;

因为没有使用 START TRANSACTION 将上面的操作当成一个事务来执行，根据 MySQL 的 AUTOCOMMIT 机制，每个操作都会被当成一个事务来执行，所以上面的操作总共涉及到三个事务。快照中除了记录事务版本号 TRX_ID 和操作之外，还记录了一个 bit 的 DEL 字段，用于标记是否被删除。

在这里插入图片描述

INSERT、UPDATE、DELETE 操作会创建一个日志，并将事务版本号 TRX_ID 写入。DELETE 可以看成是一个特殊的 UPDATE，还会额外将 DEL 字段设置为 1。

ReadView

MVCC 维护了一个 ReadView 结构，主要包含了当前系统未提交的事务列表 TRX_IDs {TRX_ID_1, TRX_ID_2, …}，还有该列表的最小值 TRX_ID_MIN 和 TRX_ID_MAX。

在这里插入图片描述

在进行 SELECT 操作时，根据数据行快照的 TRX_ID 与 TRX_ID_MIN 和 TRX_ID_MAX 之间的关系，从而判断数据行快照是否可以使用：

TRX_ID < TRX_ID_MIN，表示该数据行快照时在当前所有未提交事务之前进行更改的，因此可以使用。
TRX_ID > TRX_ID_MAX，表示该数据行快照是在事务启动之后被更改的，因此不可使用。
TRX_ID_MIN <= TRX_ID <= TRX_ID_MAX，需要根据隔离级别再进行判断：
- 提交读：该隔离界别下每一次查询都要进行一次快照读(readView)操作，如果 TRX_ID 在 TRX_IDs 列表中，表示该数据行快照对应的事务还未提交，则该快照不可使用。否则表示已经提交，可以使用。
- 可重复读：**该隔离界别下事务开始的时候进行一次快照读操作(readView)而且只进行这一次，**如果 TRX_ID 在 TRX_IDs 列表中就不能使用。因为如果可以使用的话，那么其它事务也可以读到这个数据行快照并进行修改，那么当前事务再去读这个数据行得到的值就会发生改变，也就是出现了不可重复读问题。

在数据行快照不可使用的情况下，需要沿着 Undo Log 的回滚指针 ROLL_PTR 找到下一个快照，再进行上面的判断。