1.存储引擎

1.1 存储引擎

1.常见的几种数据库引擎

InnoDB
InnoDB是事务型数据库的首选引擎，支持事务安全表（ACID），支持行锁定和外键，InnoDB是默认的MySQL引擎

MyISAM
MyISAM基于ISAM存储引擎，并对其进行扩展。它是在Web、数据仓储和其他应用环境下最常使用的存储引擎之一。
MyISAM拥有较高的插入、查询速度，但不支持事物。

链接: 几种MySQL数据库引擎优缺点对比

2.InnoDB和MyISAM的区别

1）InnoDB 支持事务，而 MyISAM 不支持。
2）InnoDB 支持外键，而 MyISAM 不支持。因此将一个含有外键的 InnoDB 表 转为 MyISAM 表会失败。
3）InnoDB 和 MyISAM 均支持 B+ Tree 数据结构的索引。但 InnoDB 是聚集索引，而 MyISAM 是非聚集索引。
4）InnoDB 不保存表中数据行数，执行 select count(*) from table 时需要全表扫描。而 MyISAM 用一个变量记录了整个表的行数，速度相当快（注意不能有 WHERE 子句）。
那为什么 InnoDB 没有使用这样的变量呢？因为InnoDB的事务特性，在同一时刻表中的行数对于不同的事务而言是不一样的。
5）InnoDB 支持表、行（默认）级锁，而 MyISAM 支持表级锁。
InnoDB 的行锁是基于索引实现的，而不是物理行记录上。即访问如果没有命中索引，则也无法使用行锁，将要退化为表锁。
6）InnoDB 必须有唯一索引（如主键），如果没有指定，就会自动寻找或生产一个隐藏列 Row_id 来充当默认主键，而 Myisam 可以没有主键。

 

2.InnoDB和MyISAM的区别

1）InnoDB 支持事务，而 MyISAM 不支持。
2）InnoDB 支持外键，而 MyISAM 不支持。因此将一个含有外键的 InnoDB 表 转为 MyISAM 表会失败。
3）InnoDB 和 MyISAM 均支持 B+ Tree 数据结构的索引。但 InnoDB 是聚集索引，而 MyISAM 是非聚集索引。
4）InnoDB 不保存表中数据行数，执行 select count(*) from table 时需要全表扫描。而 MyISAM 用一个变量记录了整个表的行数，速度相当快（注意不能有 WHERE 子句）。
那为什么 InnoDB 没有使用这样的变量呢？因为InnoDB的事务特性，在同一时刻表中的行数对于不同的事务而言是不一样的。
5）InnoDB 支持表、行（默认）级锁，而 MyISAM 支持表级锁。
InnoDB 的行锁是基于索引实现的，而不是物理行记录上。即访问如果没有命中索引，则也无法使用行锁，将要退化为表锁。
6）InnoDB 必须有唯一索引（如主键），如果没有指定，就会自动寻找或生产一个隐藏列 Row_id 来充当默认主键，而 Myisam 可以没有主键。

1.2 存储结构

1.2.1 什么是 InnoDB 的页、区、段？

页（Page）
首先，InnoDB 将物理磁盘划分为页（page），每页的大小默认为 16 KB，页是最小的存储单位。页根据上层应用的需要，如索引、日志等，分为很多的格式。我们主要说数据页，也就是存储实际数据的页。

区（Extent）
如果只有页这一个层次的话，页的个数是非常多的，存储空间的分配和回收都会很麻烦，因为要维护这么多的页的状态是非常麻烦的。

所以，InnoDB 又引入了区（Extent) 的概念。一个区默认是 64 个连续的页组成的，也就是 1MB。通过 Extent 对存储空间的分配和回收就比较容易了。

段（Segment）
为什么要引入段呢，这要从索引说起。我们都知道索引的目的是为了加快查找速度，是一种典型的用空间换时间的方法。

B+ 树的叶子节点存放的是我们的具体数据，非叶子结点是索引页。所以 B+ 树将数据分为了两部分，叶子节点部分和非叶子节点部分，也就我们要介绍的段 Segment，也就是说 InnoBD 中每一个索引都会创建两个 Segment 来存放对应的两部分数据。

Segment 是一种逻辑上的组织，其层次结构从上到下一次为 Segment、Extent、Page。

1.2.2 页由哪些数据组成？

首先看数据页的基本格式，如下图：

File Header
用于描述数据页的外部信息，比如属于哪一个表空间、前后页的页号等。

Page Header
用来描述数据页中的具体信息，比如存在多少条纪录，第一条纪录的位置等。

infimum 和 supremum 纪录
infimum 和 supremum 是系统生成的纪录，分别为最小和最大纪录值，infimum 的下一条是用户纪录中键值最小的纪录，supremum 的上一条是用户纪录中键值最大的纪录，通过 next_record 字段来相连。

User Records
用户纪录，也就是数据库表中对应的数据，这里我们说常用的 Compact 格式。

InnoDB 除了我们插入的数据外，还有一些隐藏列，transaction_id（事务ID）、roll_pointer（回滚指针）是一定添加的。

row_id 则不一定，根据以下策略生成：优先使用用户建表时指定的主键，若用户没有指定主键，则使用unique键。若unique键都没有，则系统自动生成row_id，为隐藏列。

Free Space
页中目前空闲的存储，可以插入纪录。

Page Dictionary
类似于字典的目录结构，根据主键大小，每隔 4-8 个纪录设置一个槽，用来纪录其位置，当根据主键查找数据时，首先一步到位找到数据所在的槽，然后在槽中线性搜素。这种方法比从前到后遍历页的链表的效率更快。

Page Tailer
File Header存储刷盘前内存的校验和，Page Tailer储存刷盘后的校验和。当刷盘的时候，出现异常，Page Tailer和File Header中的校验和不一致，则说明出现刷盘错误。

1.2.3 页中插入记录的过程？

1）如果 Free Space 的空间足够的话，直接分配空间来添加纪录，并将插入前最后一条纪录的 next_record 指向当前插入的纪录，将当前插入纪录的 next_record 指向 supremum 纪录。

2）如果 Free Space的 空间不够的话，则首先将之前删除造成的碎片重新整理之后，按照上述步骤插入纪录。

3）如果当前页空间整理碎片之后仍然不足的话，则重新申请一个页，将页初始化之后，按照上述步骤插入纪录

2.索引

1. 索引的几种类型或分类？

从物理结构上可以分为聚集索引和非聚集索引两类：
聚簇索引，就是将索引和数据放到一起，找到索引也就找到了数据，我们刚才看到的B+树索引就是一种聚簇索引
非聚簇索引，就是将数据和索引分开，查找时需要先查找到索引，然后通过索引回表找到相应的数据。InnoDB有且只有一个聚簇索引，而MyISAM中都是非聚簇索引。

ref:聚集索引和非聚集索引的区别

从应用上可以划分为一下几类：
普通索引：MySQL 中的基本索引类型，没有什么限制，允许在定义索引的列中插入重复值和空值，纯粹为了提高查询效率。通过 ALTER TABLE table_name ADD INDEX index_name (column) 创建；

唯一索引：索引列中的值必须是唯一的，但是允许为空值。通过 ALTER TABLE table_name ADD UNIQUE index_name (column) 创建；

主键索引：特殊的唯一索引，也称聚簇索引，不允许有空值，并由数据库帮我们自动创建；

组合索引：组合表中多个字段创建的索引，遵守最左前缀匹配规则；

全文索引：只有在 MyISAM 引擎上才能使用，同时只支持 CHAR、VARCHAR、TEXT 类型字段上使用。

2. Hash 和 B+ 树索引的区别？

Hash
1）Hash 进行等值查询更快，但无法进行范围查询。因为经过 Hash 函数建立索引之后，索引的顺序与原顺序无法保持一致，故不能支持范围查询。同理，也不支持使用索引进行排序。
2）Hash 不支持模糊查询以及多列索引的最左前缀匹配,因为 Hash 函数的值不可预测，如 AA 和 AB 的算出的值没有相关性。
3）Hash 任何时候都避免不了回表查询数据.
4）虽然在等值上查询效率高，但性能不稳定，因为当某个键值存在大量重复时，产生 Hash 碰撞，此时查询效率反而可能降低。

B+ Tree
1）B+ 树本质是一棵查找树，自然支持范围查询和排序。
2）在符合某些条件（聚簇索引、覆盖索引等）时候可以只通过索引完成查询，不需要回表。
3）查询效率比较稳定，因为每次查询都是从根节点到叶子节点，且为树的高度。

3. 为何使用B+ 树而非二叉查找树做索引？

我们知道二叉树的查找效率为 O(logn)，当树过高时，查找效率会下降。另外由于我们的索引文件并不小，所以是存储在磁盘上的。
文件系统需要从磁盘读取数据时，一般以页为单位进行读取，假设一个页内的数据过少，那么操作系统就需要读取更多的页，涉及磁盘随机 I/O 访问的次数就更多。将数据从磁盘读入内存涉及随机 I/O 的访问，是数据库里面成本最高的操作之一。
因而这种树高会随数据量增多急剧增加，每次更新数据又需要通过左旋和右旋维护平衡的二叉树，不太适合用于存储在磁盘上的索引文件。

4. 为何使用B+ 树而非 B 树做索引？

在此之前，先来了解一下 B+ 树和 B 树的区别：

B 树
B 树非叶子结点和叶子结点都存储数据，因此查询数据时，时间复杂度最好为 O(1)，最坏为 O(log n)。而 B+ 树只在叶子结点存储数据，非叶子结点存储关键字，且不同非叶子结点的关键字可能重复，因此查询数据时，时间复杂度固定为 O(log n)。

B+ 树
B+ 树叶子结点之间用链表相互连接，因而只需扫描叶子结点的链表就可以完成一次遍历操作，B 树只能通过中序遍历。

为什么 B+ 树比 B 树更适合应用于数据库索引？

1.B+ 树减少了 IO 次数。
由于索引文件很大因此索引文件存储在磁盘上，B+ 树的非叶子结点只存关键字不存数据，因而单个页可以存储更多的关键字，即一次性读入内存的需要查找的关键字也就越多，磁盘的随机 I/O 读取次数相对就减少了。

2.B+ 树查询效率更稳定
由于数据只存在在叶子结点上，所以查找效率固定为 O(log n)，所以 B+ 树的查询效率相比B树更加稳定。

3.B+ 树更加适合范围查找
B+ 树叶子结点之间用链表有序连接，所以扫描全部数据只需扫描一遍叶子结点，利于扫库和范围查询；B 树由于非叶子结点也存数据，所以只能通过中序遍历按序来扫。也就是说，对于范围查询和有序遍历而言，B+ 树的效率更高。

ref :为什么 B+ 树比 B 树更适合应用于数据库索引?

5. 什么是最左匹配原则？

最左优先，以最左边的为起点任何连续的索引都能匹配上。同时遇到范围查询(>、<、between、like)就会停止匹配。 假如建立联合索引（a,b,c）
例如：b = 2 如果建立(a,b)顺序的索引，是匹配不到(a,b)索引的；但是如果查询条件是a = 1 and b = 2或者a=1(又或者是b = 2 and b = 1)就可以，因为优化器会自动调整a,b的顺序。再比如a = 1 and b = 2 and c > 3 and d = 4 如果建立(a,b,c,d)顺序的索引，d是用不到索引的，因为c字段是一个范围查询，它之后的字段会停止匹配。

ref 左匹配原则

6. 什么是索引下推？

索引下推（Index condition pushdown） 简称 ICP，在 Mysql 5.6 版本上推出的一项用于优化查询的技术。
在不使用索引下推的情况下，在使用非主键索引进行查询时，存储引擎通过索引检索到数据，然后返回给 MySQL 服务器，服务器判断数据是否符合条件。

而有了索引下推之后，如果存在某些被索引列的判断条件时，MySQL 服务器将这一部分判断条件传递给存储引擎，然后由存储引擎通过判断索引是否符合 MySQL 服务器传递的条件，只有当索引符合条件时才会将数据检索出来返回给 MySQL 服务器。

索引条件下推优化可以减少存储引擎查询基础表的次数，也可以减少 MySQL 服务器从存储引擎接收数据的次数。

7.索引失效情况

1.Like 以%开头，索引无效；当like前缀没有%，后缀有%时，索引有效。
2.复合索引未用左列字段。最左匹配原则
3.条件中有or，要想使用or，又想让索引生效，只能将or条件中的每个列都加上索引
4.如果列类型是字符串，那一定要在条件中将数据使用引号引用起来,否则不使用索引
5.where 子句里对索引列上有数学运算，用不上索引
6.where 子句里对有索引列使用函数，用不上索引
7.WHERE字句的查询条件里有不等于号（如：WHERE column!=…），MYSQL将无法使用索引
8.如果mysql估计使用全表扫描要比使用索引快,则不使用索引，比如数据量极少的表。

8.什么是回表？

我们在索引中，有一种叫做聚集索引和非聚集索引的索引类型。
在聚集索引中，B+树上会存储这一行的全部数据，但是非聚集索引只会存储该列对应的值和相应行的主键。

是不是聚集索引的定义与主键索引很像？

其实就是的，当我们没有定义主键索引时，MYSQL会指定从左到有的第一个加了唯一索引和非空约束的列建立聚集索引，用它来代替主键索引。

聚集索引≈主键索引=唯一性约束+非空约束

那我们说了这么多？到底什么是回表查询呢？

比如有这么一张表 id name sex type
id为主键，name建立了普通索引。
比如我写下面的查询语句

select * from table where name =‘ls’
1
由于name列建立的普通索引，那么就会去走name索引，但是我们发现 name索引里面只存放了name值和对应的主键 id，并找不到我们要的 sex type的信息。那么怎么办呢？
就必须重新去主键索引查找相关值。
因为主键索引存放了这一行的完整信息，但name没有。

就会发生下面的场景

 

回表查询其实就执行了两次B+树查询，这是一个既费时又费力的操作。
因此，我们要尽可能的避免回表查询。

我们再来看看回表查询的本质是什么？是不是普通索引找不到我们要的完整信息，迫不得已要执行回表查询，再回到主键索引或者聚集索引中查询数据。

那么解决回表查询的关键就是：索引覆盖

怎么理解呢？
比如

这个就不会执行回表查询

这个就要执行回表查询，因为sex在name索引上根本查不到。

那么怎么解决呢？
就是name 与 sex 可以建立联合索引。
这就是索引覆盖，大家可以感受一下。让索引范围覆盖住我们select 的范围，就不会发生回表查询。

ref:什么是回表查询？如何避免回表查询？

3.事务

3.1 什么是数据库的事务？

数据库的事务是一个不可分割的数据库操作序列，也是数据库并发控制的基本单位，其执行的结果必须使数据库从一种一致性状态变到另一种一致性状态。事务是逻辑上的一组操作，要么都执行，要么都不执行。

3.2 什么是事务的四大特性（ACID）？

原子性： 事务是最小的执行单位，不允许分割。事务的原子性确保动作要么全部完成，要么完全不起作用
一致性： 事务执行前后，数据保持一致，多个事务对同一个数据读取的结果是相同的
隔离性： 并发访问数据库时，一个用户的事务不被其他事务所干扰，各并发事务之间数据库是独立的
持久性： 一个事务被提交之后。它对数据库中数据的改变是持久的，即使数据库发生故障也不应该对其有任何影响。

3.3 事务的并发问题？

脏读、幻读和不可重复读。
ref :并发事务带来的问题

3.4 什么是脏读、幻读和不可重复读？

脏读：一个事务读取到另一个事务尚未提交的数据。 事务 A 读取事务 B 更新的数据，然后 B 回滚操作，那么 A 读取到的数据是脏数据。

不可重复读：一个事务中两次读取的数据的内容不一致。 事务 A 多次读取同一数据，事务 B 在事务 A 多次读取的过程中，对数据作了更新并提交，导致事务 A 多次读取同一数据时，结果 不一致。

幻读：一个事务中两次读取的数据量不一致。 系统管理员 A 将数据库中所有学生的成绩从具体分数改为 ABCDE 等级，但是系统管理员 B 就在这个时候插入了一条具体分数的记录，当系统管理员 A 改结束后发现还有一条记录没有改过来，就好像发生了幻觉一样，这就叫幻读。

总结：不可重复读的和幻读很容易混淆，不可重复读侧重于修改，幻读侧重于新增或删除。 解决不可重复读的问题只需锁住满足条件的行，解决幻读需要锁表。

3.5 事务的隔离级别有哪些？

第一种隔离级别：Read uncommitted(读未提交)
如果一个事务已经开始写数据，则另外一个事务不允许同时进行写操作，但允许其他事务读此行数据，该隔离级别可以通过“排他写锁”，但是不排斥读线程实现。这样就避免了更新丢失，却可能出现脏读，也就是说事务B读取到了事务A未提交的数据

解决了更新丢失，但还是可能会出现脏读

第二种隔离级别：Read committed(读提交)
如果是一个读事务(线程)，则允许其他事务读写，如果是写事务将会禁止其他事务访问该行数据，该隔离级别避免了脏读，但是可能出现不可重复读。事务A事先读取了数据，事务B紧接着更新了数据，并提交了事务，而事务A再次读取该数据时，数据已经发生了改变。

解决了更新丢失和脏读问题

第三种隔离级别：Repeatable read(可重复读取) 数据库默认开启
可重复读取是指在一个事务内，多次读同一个数据，在这个事务还没结束时，其他事务不能访问该数据(包括了读写)，这样就可以在同一个事务内两次读到的数据是一样的，因此称为是可重复读隔离级别，读取数据的事务将会禁止写事务(但允许读事务)，写事务则禁止任何其他事务(包括了读写)，这样避免了不可重复读和脏读，但是有时可能会出现幻读。(读取数据的事务)可以通过“共享读镜”和“排他写锁”实现。

解决了更新丢失、脏读、不可重复读、但是还会出现幻读

第四种隔离级别：Serializable(可串行化)
提供严格的事务隔离，它要求事务序列化执行，事务只能一个接着一个地执行，但不能并发执行，如果仅仅通过“行级锁”是无法实现序列化的，必须通过其他机制保证新插入的数据不会被执行查询操作的事务访问到。序列化是最高的事务隔离级别，同时代价也是最高的，性能很低，一般很少使用，在该级别下，事务顺序执行，不仅可以避免脏读、不可重复读，还避免了幻读

解决了更新丢失、脏读、不可重复读、幻读(虚读)

隔离级别 脏读 不可重复读 幻读
未提交读 √ √ √
提交读 × √ √
可重复读 × × √
可串行化 × × ×

MYSQL数据库中默认的隔离级别是Repeatable read（可重复读）
ref 事务的隔离级别

3.6 ACID 特性是如何实现的？

原子性：语句要么全执行，要么全不执行，是事务最核心的特性，事务本身就是以原子性来定义的；实现主要基于undo log
持久性：保证事务提交后不会因为宕机等原因导致数据丢失；实现主要基于redo log
隔离性：保证事务执行尽可能不受其他事务影响；InnoDB默认的隔离级别是RR，RR的实现主要基于锁机制（包含next-key lock）、MVCC（包括数据的隐藏列、基于undo log的版本链、ReadView）
一致性：事务追求的最终目标，一致性的实现既需要数据库层面的保障，也需要应用层面的保障

ref ACID特性的实现原理

4.锁

1.数据库锁的作用以及有哪些锁？

当数据库有并发事务的时候，可能会产生数据的不一致，这时候需要一些机制来保证访问的次序，锁机制就是这样的一个机制。即锁的作用是解决并发问题。

从锁的粒度划分，可以将锁分为表锁、行锁以及页锁。
行级锁：是锁定粒度最细的一种锁，表示只针对当前操作的行进行加锁。行级锁能大大减少数据库操作的冲突。其加锁粒度最小，但加锁的开销也最大。
行级锁开销大，加锁慢，且会出现死锁。但锁定粒度最小，发生锁冲突的概率最低，并发度也最高。

表级锁：是粒度最大的一种锁，表示对当前操作的整张表加锁，它实现简单，资源消耗较少，被大部分MySQL引擎支持。

页级锁：是粒度介于行级锁和表级锁中间的一种锁。表级锁速度快，但冲突多，行级冲突少，但速度慢。所以取了折中的页级，一次锁定相邻的一组记录。

开销和加锁时间界于表锁和行锁之间，会出现死锁。锁定粒度界于表锁和行锁之间，并发度一般。

从使用性质划分，可以分为共享锁、排它锁以及更新锁。
共享锁（Share Lock）：S 锁，又称读锁，用于所有的只读数据操作。
S 锁并非独占，允许多个并发事务对同一资源加锁，但加 S 锁的同时不允许加 X 锁，即资源不能被修改。S 锁通常读取结束后立即释放，无需等待事务结束。

排他锁（Exclusive Lock）：X 锁，又称写锁，表示对数据进行写操作。
X 锁仅允许一个事务对同一资源加锁，且直到事务结束才释放，其他任何事务必须等到 X 锁被释放才能对该页进行访问。

使用 select * from table_name for update; 语句产生 X 锁。

更新锁：U 锁，用来预定要对资源施加 X 锁，允许其他事务读，但不允许再施加 U 锁或 X 锁。
当被读取的页将要被更新时，则升级为 X 锁，U 锁一直到事务结束时才能被释放。故 U 锁用来避免使用共享锁造成的死锁现象。

ref 数据库锁分类和总结

从主观上划分，又可以分为乐观锁和悲观锁。

乐观锁（Optimistic Lock）：顾名思义，从主观上认定资源是不会被修改的，所以不加锁读取数据，仅当更新时用版本号机制等确认资源是否被修改。
乐观锁适用于多读的应用类型，可以系统提高吞吐量。

悲观锁（Pessimistic Lock）：正如其名，具有强烈的独占和排它特性，每次读取数据时都会认为会被其它事务修改，所以每次操作都需要加上锁。

2.乐观锁和悲观锁的概念

悲观锁
总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它解锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。就像for update，再比如Java里面的同步原语synchronized关键字的实现也是悲观锁。

乐观锁
顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库提供的类似于write_condition机制，其实都是提供的乐观锁。

3.MySQL如何实现悲观锁

1、实现悲观锁利用select … for update加锁, 操作完成后使用commit来释放锁；
2、innodb引擎时, 默认行级锁, 当有明确字段时会锁一行, 如无查询条件或条件；
字段不明确时, 会锁整个表，条件为范围时会锁整个表；
3、查不到数据时, 则不会锁表。

4.什么是 MVCC 以及实现？

MVCC 的英文全称是 Multiversion Concurrency Control，中文意思是多版本并发控制，可以做到读写互相不阻塞，主要用于解决不可重复读和幻读问题时提高并发效率。
其原理是通过数据行的多个版本管理来实现数据库的并发控制，简单来说就是保存数据的历史版本。可以通过比较版本号决定数据是否显示出来。读取数据的时候不需要加锁可以保证事务的隔离效果。

ref MVCC 原理
ref MVCC详解

5.隔离级别和锁的关系？

1） Read Uncommitted （读取未提交内容）
读取数据不需要加共享锁，这样就不会跟被修改的数据上的排他锁冲突；

2） Read Committed （读取提交内容）
读操作需要加共享锁，但是在语句执行完以后释放共享锁；

3）** Repeatable Read**
读操作需要加共享锁，但是在事务提交之前并不释放共享锁，也就是必须等待事务执行完毕以后才释放共享锁；

4） SERIALIZABLE
限制性最强，因为该级别锁定整个范围的键，并一直持有锁，直到事务完成。

ref Innodb中的事务隔离级别和锁的关系

5.集群

1.主从复制

1.什么是主从复制？

主从复制是用来建立一个与主数据库完全一样的数据库环境，即从数据库。主数据库一般是准实时的业务数据库。

2.主从复制的作用？

  • 读写分离，使数据库能支撑更大的并发。
  • 高可用，做数据的热备，作为后备数据库，主数据库服务器故障后，可切换到从数据库继续工作，避免数据丢失。

6.日志

1.MySQL 中有哪些常见日志？

重做日志（redo log）：物理日志
作用是确保事务的持久性。 redo 日志记录事务执行后的状态，用来恢复未写入 data file 的已提交事务数据。

回滚日志（undo log）：逻辑日志
作用是保证数据的原子性。 保存了事务发生之前的数据的一个版本，可以用于回滚，同时可以提供多版本并发控制下的读（MVCC），也即非锁定读。

二进制日志（binlog）：逻辑日志
常用于主从同步或数据同步中，也可用于数据库基于时间点的还原。

错误日志（errorlog）
记录着 MySQL 启动和停止，以及服务器在运行过程中发生的错误的相关信息。在默认情况下，系统记录错误日志的功能是关闭的，错误信息被输出到标准错误输出。

普通查询日志（general query log）
记录了服务器接收到的每一个命令，无论命令语句是否正确，因此会带来不小开销，所以也是默认关闭的。

慢查询日志（slow query log）
记录执行时间过长和没有使用索引的查询语句（默认 10s），同时只会记录执行成功的语句。

中继日志（relay log）
在从节点中存储接收到的 binlog 日志内容，用于主从同步。

ref:MySQL中的几种日志了解

2.Undo Log

1.什么是undo log

撤销日志，在数据库事务开始之前，MYSQL会去记录更新前的数据到undo log文件中。如果事务回滚或者数据库崩溃时，可以利用undo log日志中记录的日志信息进行回退。同时也可以提供多版本并发控制下的读(MVCC)。

2.undo log生命周期

undo log产生： 在事务开始之前生成
undo log销毁： 当事务提交之后，undo log并不能立马被删除，而是放入待清理的链表，由purge线程判断是否由其他事务在使用undo段中表的上一个事务之前的版本信息，决定是否可以清理undo log的日志空间。
注意： undo log也会生产redo log，undo log也要实现持久性保护。

3.uodo log日志的作用

  • undo log日志可以实现事务的回滚操作**
    我们在进行数据更新操作的时候，不仅会记录redo log，还会记录undo log，如果因为某些原因导致事务回滚，那么这个时候MySQL就要执行回滚（rollback）操作，利用undo log将数据恢复到事务开始之前的状态。

如我们执行下面一条删除语句：

那么此时undo log会生成一条与之相反的insert 语句【反向操作的语句】，在需要进行事务回滚的时候，直接执行该条sql，可以将数据完整还原到修改前的数据，从而达到事务回滚的目的。

再比如我们执行一条update语句：

此时undo log会记录一条相反的update语句，如下：

如果这个修改出现异常，可以使用undo log日志来实现回滚操作，以保证事务的一致性。

  • undo log实现多版本并发控制 MVCC
    具体的MVCC实现机制详解看这篇博客

4.uodo log的工作原理


如上图所示：
当事务A进行一个update操作，将id=1修改成id=2。首先会修改buffer pool中的缓存数据，同时会将旧数据备份到undo log buffer中，记录的是还原操作的sql语句。此时如果事务B要查询修改的数据，但是事务A还没有提交，那么事务B就会从undo log buffer中，查询到事务A修改之前的数据，也就是id=1。此时undo log buffer会将数据持久化到undo log日志中(落盘操作)。undo日志持久化之后，才会将数据真正写入磁盘中，也就是写入ibd的文件中。最后才会执行事务的提交。

5.uodo log的存储机制

 

6.uodo log的配置参数

innodb_max_undo_log_size: undo日志文件的最大值，默认1GB，初始化大小10M
innodb_undo_log_truncate: 标识是否开启自动收缩undo log表空间的操作
innodb_undo_tablespaces: 设置独立表空间的个数，默认为0，标识不开启独立表空间，undo日志保存在ibdata1中
innodb_undo_directory: undo日志存储的目录位置
innodb_undo_logs: 回滚的个数 默认128

ref:Undo log日志详解

3.Redo Log

1.什么是Redo Log

redo log（重做日志）是InnoDB存储引擎独有的，它让MySQL拥有了崩溃恢复能力。
比如MySQL实例挂了或宕机了，重启时，InnoDB存储引擎会使用redo log恢复数据，保证数据的持久性与完整性。

redo log可以分为以下两部分

  • 存储在内存中的重做日志缓冲区（Redo Log Buffer），易丢失
  • 存储在磁盘上的重做日志文件（Redo Log File），持久化到磁盘，不易丢失

2.刷盘规则