一.MySql体系结构和存储引擎

1.1 定义数据库和实例

数据库
物理操作系统文件或其他形式文件类型集合，在MySql数据库中数据库文件可以是frm,MYD,MYI,idb结尾的文件。

实例
MySql数据库由一个后台线程以及一个共享区域组成，共享内存可以被运行的后台线程共享，数据库实例才是操作数据库文件的。

1.2 MySql体系结构

image.png

Conncetors
指定不同的语言与sql的交互，如java，php
**Management Serveices & Utilities **
系统管理和控制工具
Connection Pool
管理缓冲用户连接，线程处理等需要缓存的需求。
负责监听对 MySQL Server 的各种请求，接收连接请求，转发所有连接请求到线程管理模块。每一个连接上 MySQL Server 的客户端请求都会被分配（或创建）一个连接线程为其单独服务。而连接线程的主要工作就是负责 MySQL Server 与客户端的通信，接受客户端的命令请求，传递 Server 端的结果信息等。线程管理模块则负责管理维护这些连接线程。包括线程的创建，线程的 cache 等。
SQL Interface
接口，接受用户的SQL命令，并且返回用户需要查询的结果。比如select from就是调用SQL Interface
Parser
SQL命令传递到解析器的时候会被解析器验证和解析。解析器是由Lex和YACC实现的，是一个很长的脚本。

在 MySQL中我们习惯将所有 Client 端发送给 Server 端的命令都称为 query ，在 MySQL Server里面，连接线程接收到客户端的一个 Query 后，会直接将该 query 传递给专门负责将各种 Query 进行分类然后转发给各个对应的处理模块。

主要功能：

• 将SQL语句进行语义和语法的分析，分解成数据结构，然后按照不同的操作类 型进行分类，然后做出针对性的转发到后续步骤，以后SQL语句的传递和处理就 是基于这个结构的。
• 如果在分解构成中遇到错误，那么就说明这个sql语句是不合理的

Optimizer

SQL语句在查询之前会使用查询优化器对查询进行优化。就是优化客户端请求的 query（sql语句） ，根据客户端请求的 query 语句，和数据库中的一些统计信息，在一系列算法的基础上进行分析，得出一个最优的策略，告诉后面的程序如何取得这个 query 语句的结果

例子：使用的是“选取-投影-联接”策略进行查询。
用一个例子就可以理解： select uid,name
from user where gender = 1;
这个select 查询先根据where 语句进行选取，而不是先将表全部查询出来以后 再进行gender过滤
这个select查询先根据uid和name进行属性投影，而不是将属性全部取出以后 再进行过滤
将这两个查询条件联接起来生成最终查询结果

cache & Buffer

他的主要功能是将客户端提交 给MySQL 的 Select 类 query 请求的返回结果集 cache 到内存中，与该 query 的一个 hash 值 做一个对应。该 Query 所取数据的基表发生任何数据的变化之后， MySQL 会自动使该 query 的Cache 失效。在读写比例非常高的应用系统中， Query Cache 对性能的提高是非常显著的。当然它对内存的消耗也是非常大的。

如果查询缓存有命中的查询结果，查询语句就可以直接去查询缓存中取数据。这个缓存机制是由一系列小缓存组成的。比如表缓存，记录缓存，key缓存，权限缓存等

1.3 存储引擎

1.3.1 InnoDB存储引擎

MySql数据库从5.5.8版本开始默认支持InnoDB存储引擎，InnoDB存储引擎支持事务，行锁，外键，非锁定读，同时InnoDB通过多版本并发控制器（MVCC）来获得高并发，并且实现了SQL的四中隔离级别，默认是REPEATABLE级别，另外InnoDB使用一种next-keylocking 的策略来避免幻读现象产生，最后，InnoDB存储引擎还提供了插入缓冲，二次写，自适应哈希索引，预读等高可用功能。

对于表中数据的存储，InnoDB存储引擎采用聚集的方式，因此每张表的存储都是按主键顺序存放的，如果没有显式指定主键，InnoDB会为每一行数据生成一个六字节的RowId,并以此作为主键

1.3.2 MyISAM存储引擎

MySql数据库在5.5.8版本之前默认是支持MyISAM存储引擎的，MyISAM存储引擎由MYD和MYI组成，MYD用来存放数据文件，MYI用来存放索引文件，它不支持事务，最大的特点是它的缓冲池只缓存索引文件，不缓存数据文件。

1.4 连接MySql

1.4.1 TCP/IP

TCP/IP套接字方式是MySql数据库在任何平台下都提供的链接方式，也是使用最多的一种方式

127.0.0.1>mysql -h127.0.0.1 -uroot -p
Enter password: ******
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 718
Server version: 8.0.28 MySQL Community Server - GPL

Copyright (c) 2000, 2022, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

再通过TPC/IP连接MySql数据库时，它会先检测一张权限视图来判断客户端ip是否有权限访问数据库

1.4.2 命名管道和共享内存

1.4.3 UNIX域套接字

linux和unix环境下客户端还可以通过UNIX套接字连接数据库（socket）,但是只能客户端和MySql数据库在一台服务器上才能使用

二.InnoDB存储引擎

2.1 InnoDB存储引擎概述

InnoDB存储引擎最早由Innobase Oy公司开发，MySql数据库5.5.8B版本开始默认支持，InnoDB存储引擎支持ACID事务，支持行锁，支持MVCC，支持外键，提供一致性非锁定读，同时被设计的最有效使用内存和CPU

2.2 InnoDB存储引擎的版本

image.png

2.3 InnoDB存储引擎体系结构

image.png

2.3.1 后台线程

master Thread
核心线程，主要负责将缓冲池的数据异步刷新到磁盘，保证数据的一致性，包括脏页的刷新，合并插入缓冲池UNDO页的回收
IO Thread
InnoDB存储引擎大量使用AIO来处理写IO请求，IO Thread主要处理这些IO请求的回调处理，InnoDB1.0版本之前共有4个IO Thread ,分别是write ,read ,insert buffer ,log IO thread ,InnoDB1.X版本 开始write Thread和read Thread 分别增加到4个
Purge Thread
事务被提交后，其所使用的undolog可能不再需要了，因此需要Purge Thread来回收这些已经使用并分配的undolog,独立与master Thread执行

2.3.2 内存

缓冲池
基于磁盘的数据库通常使用缓冲池来提高数据库的整体性能，简单来说，缓冲池就一块内存区域，将磁盘读到的页存放在缓冲池中，客户端去读在缓冲池中命中则返回缓冲池数据，反之查询磁盘数据

对于数据库中页的修改操作，首先是修改缓冲池中页，然后以一定的频率刷新到磁盘（通过checkpoint机制刷新到磁盘）

可以通过配置innodb_buffer_pool_size参数设置缓冲池大小

image.png

缓冲池包含索引页，数据页，undo页，插入缓冲，自适应哈希索引，锁信息，数据字典信息等待，从InnoDB1.x开始支持多个缓冲池，每个页根据哈希值均分到不同的缓冲池、

LUR List,Free List和Flush List
数据库中的缓存池是通过LUR(最近最少使用)算法来管理缓存池的，使用频繁的页保存在LUR列表前端，而最少使用的则在尾端，优先释放尾部页。

缓存池中页的默认大小时16kb

InnoDB存储引擎对LUR算法进行了改进，新读取到的页并不是直接放在LUR列表头部，还是一个交midpoint的位置，在InnoDB存储引擎中该算法叫做midpoint insertion strategy ,默认位置在LUR列表5/8处，可有参数innodb_old_blocks_pct控制，是个百分数

重做日志缓冲
InnoDB存储引擎会先将重做日志放入这个缓冲区，按一定的频次刷新到重做日志文件当中，可通过 innodb_log_buffer_size设置重做日志缓冲区大小

以下三种情况会将重做日志缓存刷新到重做日志文件中
1.Master Thread 每一秒将重做日志缓冲刷新到重做日志文件
2.每个事务提交时会将重做日志缓冲刷新到重做日志文件
3.重做日志缓冲池剩余空间小于1/2时重做日志缓冲刷新到重做日志文件

额外内存
InnoDB存储引擎中，对内存管理是通过内存堆的方式进行的，对一些数据结构本身的内存进行分配时，需要额外的从内存池中申请，当该区域内存不足时会冲缓冲池中进行申请

2.4 Checkpoint技术

Checkpoint 技术的目的
1.缩短数据库恢复时间
2.缓冲池不够用将脏页刷到磁盘
3.重做日志不可用时，刷新脏页

当数据库宕机时，需要对Checkpoint后的重做日志进行恢复，这样可以大大减少恢复时间，此外，当缓冲池不够用时，根据LUR算法移除最近最少使用的页，若此页为脏页，则需要强制执行Checkpoint将脏页也就是页的最新版本刷回磁盘。

当数据库发生宕机时，数据库恢复不需要这部分重做日志时，那这部分重做日志就可以被覆盖，若还需要使用，那就必须强制生成Checkpoint ，将缓冲池的页至少刷新到当前重做日志的位置。

Checkpoint 分为两种
1.Sharp Checkpoint
发生在数据库关闭时将所有脏页数据刷会到磁盘，这是默认的工作方式，即参数innodb_fast_shoutdown = 1
2.Fuzzy Checkpoint
在InnoDB存储引擎内部使用，刷新部分脏页到磁盘，不是全量脏页

在InnoDB存储引擎中，可能发生以下几种Fuzzy Checkpoint
1.Master Thread Chcekpoint
Master Thread Chcekpoint 差不多每秒或每十秒的速度从缓冲池的脏页列表刷新一定数量的页回磁盘，这个过程时异步的，InnoDB 存储引擎还可以处理其他操作，用户查询线程不会阻塞
2.FLUSH_LUR_LIST Chcekpoint
InnoDB 存储引擎需要保证LRU列表中有100个空闲页可以使用，当空闲页不足时会移除LRU列表尾部的页，如果这些页中有脏页就需要Checkpoint ,MySql 5.6版本后这个检查被放在单独的线程Page Cleaner线程中执行，可通过配置innodb_lru_scan_depth配置LRU列表数量，默认1024

3.Async、sync Flush Chcekpoint
为了保证重做日志的可用性，在重做日志不可用时，需要将一些页强制刷回磁盘，这些操作都在Page Cleaner线程执行，不会阻塞用户线程

4.Dirty Page too much Chcekpoint
脏页数量太多，InnoDB 存储引擎强制将脏页刷回磁盘，保证缓冲池有足够的空闲页

2.5 master Thread工作方式

2.5.1 InnoDB 1.x之前的Master Thread

Master Thread内部有多个循环组成，主循环，后台循环，刷新循环，暂停循环，Master Thread会根据数据运行状态在这些循环之间进行切换
Loop被称为主循环，分为两大类操作每秒操作和每10秒操作

void master_thread(){
  loop;
  for(int i=0; i < 10 ;i++){
    do thing once per second
    sleep 1 second if necessary;
  }
  do things once per ten seconds
  goto loop;
}

每秒一次的操作包括
1.日志缓冲刷到磁盘，即使事务还没有提交
2.合并插入缓冲
3.最多刷100个缓冲池中的脏页到磁盘
4.如果当前没有用户活动切换到background loop
每10一次的操作包括
1.刷新100个脏页到磁盘
2.合并最多5个插入缓冲
3.将日志缓冲刷到磁盘
4.删除无用undo页
5.刷新100个或10脏页到磁盘

2.5.2 InnoDB 2.x之前的Master Thread

2.5.3 InnoDB 2.x的Master Thread

从Master Thread分离出刷新脏页的操作，单独线程 Page cleaner Thread处理

2.6 InnoDB存储引擎关键特性

2.6.1 插入缓冲

Insert buffer
Insert buffer和数据页一样是一个物理组成部分。

聚集索引的插入一般是按照主键递增的顺序进行插入的，但是对于非聚集索引的插入，数据页还是按照主键顺序存放的，只是非聚集索引叶子节点插入不再是顺序的了需要离散访问非聚集索引页，这是由B+树的特性决定的，比较耗性能

Insert buffer对于非聚集索引的插入或更新操作不是每一次插入索引页中，而是先判断非聚集索引页是否存在缓冲池中，存在则直接插入，不存在则放到Insert Buffer对象中，再按照一定频次将Insert Buffer和辅助索引叶子节点合并，多个插入操作合并到一次操作中提高非聚集索引插入的性能。

使用Insert Buffer是要满足两个条件
1.索引是辅助索引
2.索引不是唯一的

change buffer
待完续
Insert buffer内部实现
待完续

2.6.2 两次写，

double write 保证InnoDB 存储引擎数据的可靠性，当InnoDB 存储引擎发生部分写失效时（写的过程中宕机了），容易发生数据丢失，这个时候如果重做日志没有记录，恢复数据则需要副本还原数据页

double write分两部分，内存中的doublewrite buffer ,大小为2M，另一个是物理磁盘上共享表空间连续的128个页，即2个区，大小2M，在对缓冲池脏页刷新时，并不直接写入磁盘，先通过memcpy函数复制到内存中的doublewrite buffer中，之后通过doublewrite buffer分两次，每次1MB写入共享表空间的磁盘上，然后调用fsync函数同步磁盘

image.png

2.6.3 自适应哈希索引

InnoDB 存储引擎会监控表上的索引查询，如果检测到建立哈希索引可以提升查询效率，则建立哈希索引，称为自适应哈希索引（AHI），AHI是通过缓冲池中的B+树页构造的，建立很快，不需要对整张表建立哈希索引，InnoDB 存储引擎会根据访问频率和模式自动为一些热点数据建立哈希索引

使用AHI的要求
1.连续访问模式必须一样，如（a,b）联合索引页访问必须遵循最左原则，访问模式指的是查询条件
2.通过相同模式访问超过100次，数据页通过该模式访问N次，其中N=页中记录* 1/16

2.6.4 异步IO

为了提高磁盘操作性能，当前数据库都是采用AIO的方式来处理磁盘操作的，InnoDB 存储引擎也是。

当一次查询需要扫描多个索引页时，每个扫描索引页都需要磁盘操作，这样用户可以异步发出多个IO请求，同时扫描多个索引页，等待所有IO操作完成

AIO的优势时可以IO Merge 将多个IO合并成一个IO,可以提高IOPS性能。

2.6.5 刷新临接页

当一个脏页在刷新时，InnoDB 存储引擎会检查该页所在区域的所有页，如果是脏页，一起刷新
可通过参数innodb_flush_neighbors开启关闭该功能，固态硬盘下 建议设置成0 ，关闭该功能

2.7 启动和关闭

关闭时，参数innodb_fast_shoutdown影响InnoDB 存储引擎的行为，该参数取值如下
值为0时
在mysql数据库关闭时，InnoDB 存储引擎需要完成所有full purge和merge insert buffer,并且将所有脏页刷新到磁盘
值为1时
默认值，表示不需要完成full purge和merge insert buffer操作，但是缓冲池中的脏页数据还是要刷新到磁盘
值为2时
不做full purge和merge insert buffer操作，也不将缓冲池脏页数据刷到磁盘，而是将日志读写入日志文件，下次启动mysql时会进行恢复操作

三.文件

待完续

四.表

4.1索引组织表

InnoDB存储引擎中，表都是根据主键顺序存放的，这种存储方式称为索引组织表，每个表都有一个主键，如果没有显式创建，InnoDB会为表自动创建或选择其他索引当做主键，规则如下
1.表中有非空唯一索引，有，则该列为主键
2.不符合上面条件，InnoDB自动创建一个6字节大小的主键

4.2 InnoDB 逻辑存储结构

image.png

4.2.1 表空间

InnoDB逻辑存储最高层，所有数据都存放在表空间下面

4.2.2 段

表空间由各个段组成，常见的段有数据段（B+树的叶子节点），索引段（B+树的非叶子节点），回滚段等等。

4.2.3 区

区由连续的页组成的空间，任何情况下区大小为1MB，为保证区中页的连续性，InnoDB一次申请4-5个区，默认情况下，InnoDB中页大小为16KB，即一个区有64个连续的页组成

4.2.4 页

页是InnoDB磁盘管理的最小单位，默认大小为16KB，可通过参数innodb_page_size 配置默认大小，常见的页有
1.数据页
2.undo页
3.系统页
4.事务数据页
5.插入缓冲位图页
6.插入缓冲空闲列表页
7.未压缩二进制大对象页
8.压缩二进制大对象页

4.2.5 行

InnoDB存储引擎中数据都是按行进行存储的，每个页最多存放16KB/2-200行的记录，即7299行数据

4.3 InnoDB行记录格式

待完续

4.4 InnoDB数据页结构

image.png

4.4.1 File Header

File Header 用来记录一些头信息，由8部分组成，共38字节，如下图

image.png

4.4.2 Page Header

用来记录数据页的状态信息，由14部分组成，共56字节，如下图

image.png

4.4.3 Infimun 和Supremun Records

用来限定记录的边界，Infimun 记录比任何主键都要小的值，Supremun 记录比任何可能值都要大的值，这两个值在页被创是定义，不会被删除

image.png

4.4.4 User Records 和 Free Space

User Records 记录的数据，Free Space 空闲列表，删除一行后，会加入其中

4.4.5 Page Directory

页目录，存放记录在页中的相对位置

4.4.6 File Trailer

为检测是否完整写入磁盘，InnoDB存储引擎的页设置了File Trailer部分。
File Trailer 只有一个FIL_PAGE_END_LSN 部分，8字节，前4字节代表该页的checksum值，最后4字节和File Header 中的FIL_PAGE_LSN相同，将这两个值与File Header中的FIL_PAGE_SPACE_OR_CHKSUM和FIL_PAGE_LSN值进行比较，看是否一致，以此保证页的完整性

4.4.7 数据页结构案例分析

待完续

4.5 Named File Formats 机制

待完续

4.6 约束

待完续

4.7 视图

待完续

4.8 分区表

待完续

五.索引与算法

5.1 B+树

5.1.1 B+树的插入

如下图一个B+树结构，高度为2，每页存放4条记录，扇出为5

image.png

插入规则

image.png

插入示例
1.插入28，符合条件1，leaf page 和 index page 都没满，直接插入叶子节点

image.png

2.插入70，符合条件2，leaf page满了，index page 没满

image.png

3.插入95，符合条件3，leaf page 和 index page 都满了

image.png

另外B+树提供了类似平衡二叉树的旋转功能，尽量避免leaf page和index page的拆分，因为拆分也需要耗时处理。
当leaf page已经满了，但是其他leaf page未满时，这个时候不会拆分而是将插入数据选转到其他leaf page，如下图插入70

image.png

55上旋，50进入前面一个leaf page，这样当前leaf page就空出来一个位置插入70了

5.1.2 B+树的删除

B+树使用填充因子来控制删除树的变化，50%是填充因子可设置的最小值，删除规则如下

image.png

1.删除70

image.png

image.png

3.删除60

image.png

5.2 B+树索引

数据库中B+树索引高度一般在2-4，也就是查询一次IO次数最多就是4次，另外B+树索引可以分为聚集索引和辅助索引，高度平衡，叶子节点存放所有数据。

5.2.1 聚集索引

聚集索引就是按照每张表的主键构造的一颗B+树，叶子节点存放整张表记录数据，叶子节点也成为数据页，每个数据页都通过一个双向链表进行链接，每张表只能拥有一个聚集索引，因为数据页只能按照一颗B+树进行排序。

聚集索引的存储不是物理上连续的而是逻辑上连续的，有两点
1.页通过双向链表链接，页按照主键的顺序排序
2.每个页中的记录也是按照双向链表进行维护的

5.2.2 辅助索引

辅助索引的叶子节点并不存放数据，而是该表的聚集索引键，辅助索引并不影响数据在聚集索引中的存储，因此每张表可以有多个辅助索引，当通过辅助索引来查找数据时，InnoDB存储引擎会遍历辅助索引并通过叶级别的指针找到指向主键索引的主键，然后通过主键索引来找到对应的数据

5.2.3 B+树索引的分裂

待完续

5.2.4 B+树索引的管理

待完续

5.3 Cardinality 值

待完续

5.4 B+树索引的使用

5.4.1 联合索引

联合索引指在一张表上的多进行索引。
1.何时使用联合索引？
查询条件遵循最左原则时可以使用联合索引,如下图（a,b）两列组成的联合索引树

image.png

当查询where a = xxx and b= xxx时，或者where a=xxx 都可以使用联合索引，但是如果查询where b=xxx就不能使用联合索引了，因为此时叶子节点b的顺序时错乱的1，2，1，2，4，1，2

5.4.2 覆盖索引

即从辅助索引中就可以得到查询记录，不需要查询聚集索引中的记录，辅助索引不包含正行记录的信息，大小远小于聚集索引，因此可以减少IO操作。

5.4.3 优化器选择不适用索引的情况

待完续

5.4.4 索引提示

待完续

5.4.5 Multi-Rang Read优化

待完续

5.4.6 Index Condition PushDown优化

待完续

5.5 哈希算法

待完续

5.6 全文检索

待完续

六.锁

6.1 什么时锁

在并发操作共享数据下保证数据一致性的机制

6.2 lock与 latch

6.2.1 latch 锁

轻量级锁，要求锁时间短，否则性能很差，分为两类，mutex(互斥量)和rwlock(读写锁)，用来保证并发操作临界资源的正确性，同时没有死锁检测的机制

6.2.2 lock锁

用来锁定数据库中的对象，例如表，页，行，并且一般情况lock在事务提交或回滚后释放（不同隔离级别不一样），

image.png

6.3 InnoDB中的锁

6.3.1 锁的类型

InnoDB中实现了两种标准的行级锁
1.共享锁（S LOCK）
允许读一行数据
2.排他锁( X LOCK)
允许事务删除或更新一行数据

image.png

为了更细力度加锁，InnoDB提供了额外的意向锁，意向锁即为表锁，支持两种意向锁
1.意向共享锁（IS LOCK）
事务想获取表中某几行的共享锁
2.意向排他锁（IS LOCK）
事务想获得表中某几行的排他锁

image.png

6.3.2 一致性非锁定读

指的是InnoDB存储引擎通过多版本并发控制的方式来读取当前执行时间数据库中的数据，如果读取的数据正在执行delete或者update操作这个读操作并不会等到锁释放，而是读取一个快照数据。

image.png

快照指的是该行数据指的版本，通过undo段实现的，同时一个数据不止一个版本，不同事务隔离级别下读取的数据快照是不一样的“读已提交”隔离级别快照读的是改行数据最新的一个版本，“可重复读”隔离级别下读的是当前事务开始的行数据

6.3.3 一致性锁定读

InnoDB存储引擎对select 语句支持两种了一致性锁定读

select * from table for update
select * from table lock in share mode

6.3.4 自增长与锁

对于每个自增长的表都有一个自增长的计数器，每添加一条记录，计数器就会+1，实现方式称做AUTO-INC locking,实际上是一种特殊的表锁，不用等待之前插入事务提交，但是需要等待前一条数据插入完成，所以大量数据插入时也会影响性能。

6.3.5 外键和锁

待完续

6.4 锁的算法

6.4.1 行锁的3种算法

1.Record lock
单个行记录加锁
2.Gap lock
间隙锁 锁定一定范围记录，但是不包含记录本身
3.Next key lock
间隙锁+行锁 锁定一定范围记录，包含记录本身

Record lock锁住索引记录，如果表没有创建索引，则会使用隐式主键来进行锁定
Next key lock算法下，Innodb对于行的查询（for update）都是使用这种锁定算法

6.4.2 Phantom Problem

Phantom Problem 是指同一事务下，执行多次相同的sql，查询的结果不一样，第二次查询可能返回之前查询不存在的数据。·（强调其他事务对数据的新增或删除）

InnoDB存储引擎再默认事务隔离级别Repeatable Read 下采用Next key lock机制来避免Phantom Problem（幻读）

6.5 锁的问题

InnoDB存储引擎中，锁会带来三个问题

6.5.1 脏读（强调读到未提交数据）

脏数据是指事务对数据库缓冲池进行了修改但是还没有事务提交的数据。脏读指的是不同事务下，当前事务可以读到另外事务未提交的数据。

image.png

6.5.2 不可重复读（强调其他事务对数据的修改）

不可重复读是指一个事务内多次读取同一数据集合，多次读取中间过程中其他事务对该数据集做了一些DML操作，导致当前事务前后读取同一数据集不一致。

6.5.3 丢失更新

待完续

6.6 阻塞

InnoDB存储引擎通过参数innodb_lock_wait_timeout 来控制等待时间，默认50秒，innodb_rollback_on_timeout用来配置是否再等待超时后进行事务回滚。默认是OFF ,不回滚

6.7 死锁

死锁是指两个或两个以上的事务在执行过程中，因争夺锁资源而造成相互等待的一种现象

image.png

6.8 锁升级

待完续

七.事务

7.1 事务分类

1 扁平事务
2 带有保存点的扁平事务
3 链事务
4 嵌套事务
5 分布式事务

7.2 事务的实现

原子性，持久性，一致性通过数据库的redo log 和undo log 实现，其中，redo log 称为重做日志，保证事务原子性和持久性，undo log 保证事务一致性。

7.2.1 redo

基本概念
重做日志用来实现事务的持久性，重做日志分为两种，内存中的重做日志缓冲，和重做日志文件，InnoDB存储引擎通过Force Log at commit 机制实现事务的持久性，当事务提交时，必须将事务所有日志写入重做日志文件持久化

每次将重做日志缓冲写入重做日志文件时，为了确保写入重做日志文件，InnoDB存储引擎都需要调用一次fsync操作

参数innodb_flush_log_at_trx_commit 用来控制日志刷新到磁盘的策略，默认是1，表示事务提交时必须调用一次fsync操作，0表示事务提交不进行写入重做日志文件操作，2表示事务提交时将重做日志写入文件系统缓冲，不写入磁盘，也不进行fsync操作

Mysql数据库中还有一种二进制日志，即binlog日志，用来进行POINT-IN-TIME 的恢复和主从复制环境的简历，它和重做日志有着本质的区别，
1.重做日志时Innodb存储引擎产生的，binlog是Mysql数据库产生的
2.binlog记录的是对应的sql语句，重做日志记录的是对于每个页的修改
3.两种日志写入磁盘时间点不一样，binlog在事务提交后完成一次写入，重做日志在事务操作过程中不断写入

log black
待完续
log group
待完续
log 重做日志格式
待完续
LSN
待完续
恢复
待完续

7.2.2 undo

概念
undo日志可以将数据回滚到之前的样子，undo存放在数据库内部的一个特殊段中，称为undo段，在表空间中。

存储管理

待完续

7.2.3 purge

待完续

7.2.4 group commit

待完续

八.备份与恢复

待完续

九.性能调优

待完续