数据库篇--MySql

[lukaliou123]

1.什么是数据库，数据库管理系统，数据库系统，数据库管理员

数据库：数据库就是信息的集合或者说数据库是由数据库管理系统管理的数据的集合
数据库管理系统：数据库管理系统（DATABASE MaNAGEMENT System 简称 DBMS）是一种操纵和管理数据库的大型软件，通常用于建立、使用和维护数据库
数据库系统：数据库系统（Data Base System, 简称DBS）通常由软件、数据库和数据管理员（DBA）组成。
数据库管理员:数据库管理员，负责去那面管理和控制数据库系统

2.主键和外键有什么区别

主键（主码）：主键用于唯一标识一个元组，不能有重复，不允许为空。一个表只能有一个主键。
外键（外码）：外键用来和其他表建立联系用，外键是另一表的主键，外键是可以有重复的，可以是控制。一个表可以有多个外键。

3.什么是ER图

ER图也称实体-联系图（Entity Relationship Diagram），提供了表示实体类型、属性和联系的方法，用来描述现实世界的概念模式。它是描述现实世界关系概念莫ing的优先方法。是表示概念关系模型的一种方式
这是一个学生选课的ER图，每个学生可以选若干门课程，同一门课程也可以被若干人选择，所以它们之间的关系是多对多（M:N），其他也有1：1，1：N

4.关系型数据库和非关系型数据库

1.关系型数据库是使用行和列来确定数据关系的数据库，每一行代表一条记录，每一段代表一个字段。表之间通过主键外键来连接，通常遵循范式，第一范式是保证每列最小化，第二范式是消除部份依赖，第三范式是消除传递依赖（高强度连接主键，似乎和B+树的聚簇索引有关？），来消除数据冗余和提高一致性

2.非关系型数据库更为灵活，不需要预定义数据结构，它的数据结构更像是键值对，JSON文档或者是宽列存储等，这样可以更自由地存储和查询数据。

使用场景：关系型数据库适合存储结构化的、需要进行复杂查询的数据，而非关系型数据库更适合处理大量的非结构化数据，或者需要快速读写的场景。在实际应用中，很多大型系统会同时使用关系型数据库和非关系型数据库，以求在不同的场景中都能发挥出最大的效率。

[lukaliou123]

4.数据库范式Normalization

数据库的设计范式是数据库设计所需要满足的规范
1.1NF(第一范式)：属性（对应于表中的字段）不能再被分割，也就是这个字段只能是一个值，不能再分为多个其他的字段了。1NF是所有关系型数据库的最基本要求，也就是说关系型数据库中创建的表一定满足第一范式
2.2NF（第二范式）：2NF在1NF的基础上，消除了非主流属性对于主键的部份函数依赖，对主键完全依赖。如下图所示，展示了第一范式到第二范式的过渡。第二范式在第一范式的基础上增加了一个列，这个列成为主键，非主属性都依赖于主键.

一些重要概念：
函数依赖（functional dependency）:若在一张表中，在属性（或属性组）X的值确定的情况下，必定能确定属性Y的值，那么就可以说Y函数依赖于X,写作X->Y.

部分函数依赖(partial functional dependency):如果：X->Y,并且X的一个真子集X0，使得X0->Y,则称Y对X部分函数依赖。比如学生基本信息表R中（学号，身份证号，姓名）；（学号）->（姓名），（身份证号）->（姓名）；所以姓名部分函数依赖与（学号，身份证号）.

完全函数依赖（Full functional dependency）: ：在一个关系中，若某个非主属性数据项依赖于全部关键字称之为完全函数依赖。比如学生基本信息表 R（学号，班级，姓名）假设不同的班级学号有相同的, 班级内学号不能相同，在 R 关系中，（学号，班级）->（姓名），但是（学号）->(姓名)不成立，（班级）->(姓名)不成立，所以姓名完全函数依赖与（学号，班级）；

传递函数依赖：在关系模式 R(U)中，设 X，Y，Z 是 U 的不同的属性子集，如果 X 确定 Y、Y 确定 Z，且有 X 不包含 Y，Y 不确定 X，（X∪Y）∩Z=空集合，则称 Z 传递函数依赖(transitive functional dependency) 于 X。传递函数依赖会导致数据冗余和异常。传递函数依赖的 Y 和 Z 子集往往同属于某一个事物，因此可将其合并放到一个表中。比如在关系 R(学号 , 姓名, 系名，系主任)中，学号 → 系名，系名 → 系主任，所以存在非主属性系主任对于学号的传递函数依赖。

3.3NF:3NF在2NF的基础之上，消除了非主属性对于码的传递函数依赖，符合 3NF 要求的数据库设计。基本上解决了数据冗余过大，插入异常，修改异常，删除异常的问题。比如在关系 R(学号 , 姓名, 系名，系主任)中，学号 → 系名，系名 → 系主任，所以存在非主属性系主任对于学号的传递函数依赖，所以该表的设计，不符合 3NF 的要求。

总结：
1NF属性不可再分
2NF：1NF 的基础之上，消除了非主属性对于码的部分函数依赖。
3NF：3NF 在 2NF 的基础之上，消除了非主属性对于码的传递函数依赖 。

第一范式，要求将列尽可能最小的分割，希望消除某个列存储多个值的冗余的行为
比如用户表中的地址信息，拆分为省、市这种明确的字段，可以按独立的字段检索、查询
第二范式，要求唯一的主键，且不存在对主键的部分依赖，希望消除表中存在冗余(多余)的列
比如订单表中的商品分类、详情信息，只需要由商品信息表存储一份即可。
第三范式，要求没有间接依赖于主键的列，即仍然是希望消除表中冗余的列
比如用户表中不需要存储额外的 其所在城市的人口、城市特点等信息。

[lukaliou123]

5.MySql索引

1.何为索引
索引是一种用于快速查询和检索数据的数据结构。常见的索引结构有：B树，B+树和Hash。

5.2．索引的优缺点：
优点：
1.使用索引可以大大加快数据的检索速度（大大减少检索的数据量），这也是创建索引的最主要的原因
2.通过创建唯一性索引，可以保证数据库表中每一行数据的唯一性

缺点：
1.创建索引和维护索引需要耗费很多时间。当对表中的数据进行增删改的时候，如果数据有索引，那么索引也需要动态的修改，会降低SQL执行效率
2.索引需要使用物理文件存储，也会耗费时间。

索引不一定能提高查询性能，如果数据量不大，也没有很大提升

例子：

[lukaliou123]

6.索引的数据结构

1.哈希表：
参考collection篇，但MySql没用这个，一个是因为哈希冲突，一个是因为哈希索引不能按顺序和范围查询

2.B树和B+树
a)MySql使用B+树
b)两者的区别
1.在B树中，你可以将键和值存放在内部节点和叶子节点；但在B+树种，内部节点都是键没有值，叶子节点同时存放键和值
2.B+树的叶子节点有一条链相连，而B树的叶子节点各自独立
3.B 树的检索的过程相当于对范围内的每个节点的关键字做二分查找，可能还没有到达叶子节点，检索就结束了。而 B+树的检索效率就很稳定了，任何查找都是从根节点到叶子节点的过程，叶子节点的顺序检索很明显。

区别补充

B树和B+树都是自平衡的多路搜索树，它们在数据库中被广泛用作索引结构。然而，对于数据库这种磁盘存储系统，B+树更有优势。这主要基于以下几点原因：

更适合磁盘或其他直接访问辅助设备: 在B+树中，所有记录节点都是按照键值的大小顺序存放在同一层级上，因此在进行区间查询时只需要对树的叶子节点层进行遍历，相比于B树在磁盘上来回跳跃，B+树查询效率更高。

查询效率更稳定: 在B+树中，所有查询都要走到叶子节点，因此每次搜索的路径长度相同，导致每个数据的查询效率相等，也就是查询效率稳定。而在B树中，不同的键值查询路径长度可能不同，查询效率会有所波动。

更高的空间利用率: 在B+树中，所有的键值都出现在叶子节点，而且叶子节点的指针都指向相邻的叶子节点。因此，内部节点可以存储更多的分支因子，从而减少了树的高度，减少了查询时的磁盘I/O次数，也就提高了查询效率。

所以在大多数的数据库索引设计中，更倾向于使用B+树而不是B树

[lukaliou123]

7.何为数据库事务

事务是逻辑上的一组操作，要么都执行，要么都不执行。
数据库事务可以保证多个对数据库的操作（也就是SQL语句）构成一个逻辑上的整体。构成这个逻辑上的整体的这些数据库操作遵循：要么全部执行成功，要么全部不执行。
关系型数据库事物都有ACID特性

8.何为 ACID 特性呢？

1.原子性（Atomicity）：事务是最小的执行单位，不允许分割。事物的原子性确保动作要么全部完成，要么不起作用
2.一致性（Consistency）:执行事务前后，数据保持一致，例如转账业务中，无论事务是否成功，转账者和收款人的总额应该是不变的
3.隔离性（Isolation）:开发访问数据库时，一个用户的事务不被其他事物所感染，各并发事务之间数据库是独立的。
4.持久性（Durability）:一个事务被提交之后。他对数据库中枢的改变是持久的，即使数据库发生故障也不应该对其有任何影响

[lukaliou123]

9.数据事物的实现原理

以InnoDB引擎为例来简单说一下
MySQL InnoDB引擎通过 redo log(重做日志)保证事务的持久性，使用undo log(回滚日志)来保证事务的原子性
MySQL InnoDB引擎通过锁机制、MVCC等手段来保证事务的隔离性（默认支持的隔离级别是REPEATABLE-READ）。
保证了事务的持久性、原子性、隔离性之后，一致性才能得到保障。
https://www.cnblogs.com/kismetv/p/10331633.html

10.并发事务带来哪些问题?

事务并发运行，经常会操作相同的数据来完成各自的任务，可能会导致以下问题：
1.脏读（Dirty read）:当一个事务正在访问数据并且对数据进行了修改，而这种修改还没有提交到数据库中，这时另外一个事务也访问了这个数据，然后使用了这个数据。因为这个数据是还没有提交的数据，那么另外一个事务读到的这个数据是“脏数据”，依据“脏数据”所作的操作可能是不正确的

2.丢失操作（Lost to modify）: 指在一个事务读取一个数据时，另外一个事务也访问了该数据，那么在第一个事务中修改了这个数据后，第二个事务也修改了这个数据。这样第一个事务内的修改结果就被丢失，因此称为丢失修改。例如：事务 1 读取某表中的数据 A=20，事务 2 也读取 A=20，事务 1 修改 A=A-1，事务 2 也修改 A=A-1，最终结果 A=19，事务 1 的修改被丢失。

3.不可重复读（Unrepeatable read）: 指在一个事务内多次读同一数据。在这个事务还没有结束时，另一个事务也访问该数据。那么，在第一个事务中的两次读数据之间，由于第二个事务的修改导致第一个事务两次读取的数据可能不太一样。这就发生了在一个事务内两次读到的数据是不一样的情况，因此称为不可重复读。

4.幻读（Phantom read）：幻读与不可重复读类似。它发生在一个事务（T1）读取了几行数据，接着另一个并发事务（T2）插入了一些数据时。在随后的查询中，第一个事务（T1）就会发现多了一些原本不存在的记录，就好像发生了幻觉一样，所以称为幻读。

不可重复读和幻读区别：
不可重复读的重点是修改比如多次读取一条记录发现其中某些列的值被修改，幻读的重点在于新增或者删除比如多次读取一条记录发现记录增多或减少了。

[lukaliou123]

11.事务隔离级别有哪些?

SQL便准定义了四个隔离级别：
1.READ-UNCOMMITTED（读取未提交）：最低的隔离级别，允许读取尚未提交的数据变更，可能会导致脏读、幻读或不可重复读。
2.READ-COMMITTED(读取已提交)：允许读取并发事务已经提交的数据，可以阻止脏读，但是幻读或不可重复读仍有可能发生。
3.REPEATABLE-READ(可重复读)：对同一字段的多次读取结果都是一致的，除非数据是被本身事务自己所修改，可以阻止脏读和不可重复读，但幻读仍有可能发生
4.SERIALIZABLE(可串行化)：最高的隔离级别，完全服从 ACID 的隔离级别。所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。

SQL的默认隔离级别是可重复读

细说不可重复读

不可重复读主要是指在一个事务内，多次读取同一数据，读出的结果是不一致的。 这是因为在这个事务读取数据的过程中，有其他事务同时修改了这些数据并提交，那么每次读取的数据就可能会不一样。例如，你读取了一个商品的价格，然后另一个事务修改了这个商品的价格并提交，你再次读取这个商品的价格，就会发现价格已经改变，这就是不可重复读。

那么，如何解决不可重复读的问题呢？

数据库采用锁的概念来解决这个问题。在可重复读（Repeatable read）级别，数据库引擎会在读取数据时，对读取的数据加共享锁（也叫读锁）。这样其他事务就无法修改这些数据，只能进行读取，直到当前事务完成（提交或回滚），共享锁才会被释放。

同时，当事务试图修改数据时，也会尝试对数据加排他锁（也叫写锁）。如果这些数据被其他事务的共享锁锁住，那么这个事务就会被阻塞，直到共享锁被释放。

因此，通过锁机制，数据库能够确保在同一事务中，多次读取同一数据会得到一致的结果，从而避免了不可重复读。

不过需要注意，这种机制能够避免不可重复读，但可能无法避免幻读。因为新插入的行并不会被当前事务锁住，所以还是可能会出现幻读的情况。

补充：RR和RC的底层原理，涉及MVCC

在RR（Repeatable Read）事务隔离级别下：

1.在事务开始时创建一个快照（snapshot），事务中所有的读操作都会基于这个快照来读取数据，所以在这个事务内，读取的数据是一致的，也就是“可重复读”。这种方式就是“快照读”。
2.对于写操作（包括update和delete）也就是“当前读”，则直接对最新版本的数据进行操作，并加上必要的锁，这样就保证了数据的一致性。
通过以上方式，RR级别下避免了脏读、不可重复读，而对于幻读，InnoDB存储引擎使用next-key锁来避免。
|---- 开始事务 ---- 创建快照 ---- 读操作基于这个快照 ---- 写操作直接修改最新的数据 ---- 提交事务 ----|

在RC（Read Committed）事务隔离级别下：

1.在每次查询开始时创建一个快照。也就是说，同一事务内，如果多次执行同样的查询，可能会看到不同的结果，因为每次查询都可能会有一个新的快照。这种方式也是一种“快照读”。
2.写操作（当前读）和RR级别相同，都是直接操作最新版本的数据，并加上必要的锁。
3.RC级别只能保证不会出现脏读，对于不可重复读和幻读，并没有保证，因为每次查询都有可能产生新的快照，所以数据可能会有变化。
|---- 开始事务 ---- 每次查询时创建快照 ---- 读操作基于最新的快照 ---- 写操作直接修改最新的数据 ---- 提交事务 ----|

补充：幻读和不可重复读的区别，以及解决幻读的机制

区别

不可重复读"是指在一个事务内，多次读同一数据，由于其他提交的事务所做的更新导致多次读取结果不一致。在MVCC模型下，读操作读取的是快照数据，不会看到其他并发事务对该数据的修改，因此可以避免"不可重复读"。

"幻读"是指在一个事务内，多次查询的结果集不一样。注意和"不可重复读"的区别，**"幻读"是针对的结果集，而不是单个数据。**比如一个事务内两次查询，第一次查询了10条数据，但是第二次查询却变成了11条，这就是幻读。

MVCC可以解决"不可重复读"，但不能解决"幻读"。这是因为MVCC解决的是同一行数据的并发修改带来的问题，但对于整个结果集的并发插入或删除，MVCC并不能有效处理。

在实践中，解决"幻读"常常会采用范围锁（比如Next-Key Locks in InnoDB）。这样的锁不仅锁定了查询涉及的索引记录，还锁定了索引范围，防止其他事务在该范围内插入新的记录。当然，这种方式带来的副作用是会降低并发性能。

范围锁

范围锁（Next-Key Locks）是InnoDB用于防止幻读的一种锁定机制。它主要的作用是锁定一定范围内的数据，以保证在一个事务执行期间，其他事务不能在这个范围内插入新的数据，从而造成幻读现象。

Next-Key Locks实际上包括两部分：记录锁（Record Lock）和间隙锁（Gap Lock）。

记录锁：锁定索引记录本身。

间隙锁：锁定索引记录之间的“间隙”。这就意味着其他事务不能在这个间隙中插入新的记录。

所以Next-Key Locks就是记录锁和间隙锁的结合。当InnoDB对一条记录进行搜索时，它会在该记录上设置一个记录锁，并在前后两个记录之间设置一个间隙锁。这样，就保证了在这个事务执行期间，其他事务不能在这个范围内插入新的数据，从而避免了幻读。

例如，假设有一个索引的键值是1，3，5，7，9。如果一个事务对键值为5的记录进行查询并加锁，那么InnoDB会在这个记录上加一个记录锁，并且在键值3和5之间以及5和7之间加间隙锁。这样就防止了其他事务在这个范围内插入新的记录。

[lukaliou123]

12.MySQL存储引擎MyISAM与InnoDB索引的区别

1.MyISAM:B+Tree叶子节点的data域粗放的是数据记录的地址。在索引检索的时候，首先按照B+Tree搜索算法搜索索引，如果指定的key存在，则取出其Data域的值，然后以data域的值为地址读取相应的数据记录，这是“非聚簇索引”

2.InnoDB: 其数据文件本身就是索引文件。相比MyISAM，索引文件和数据文件是分离的，其表数据文件本身就是按B+Tree组织的一个索引结构，树的叶节点data域保存了完整的数据记录。这个索引的key是数据表的主键，因此InnoDB表数据文件本身就是主索引。这被称为“聚簇索引（或聚集索引）” 。而其余的索引都作为辅助索引，辅助索引的data域存储相应记录主键的值而不是地址，这也是和MyISAM不同的地方。在根据主索引搜索时，直接找到key所在的节点即可取出数据；在根据辅助索引查找时，则需要先取出主键的值，再走一遍主索引。 因此，在设计表的时候，不建议使用过长的字段作为主键，也不建议使用非单调的字段作为主键，这样会造成主索引频繁分裂。

B+树作为一种平衡树，确保了查找，插入，删除的时间复杂度为O(log n)

补充

1.事务支持：InnoDB引擎支持事务，有提交、回滚操作，而MyISAM引擎不支持。

2.锁机制：InnoDB引擎支持行级锁，更适合处理大量并发操作，MyISAM则只支持表级锁，适合读取操作比较多的场景。

3.存储方式：MyISAM表把表级别的元数据存储在.frm文件中，数据文件在.MYD文件中，索引文件在.MYI文件中；而InnoDB表把表级别的元数据存储在.frm文件中，数据和索引都存储在.ibd文件中，或者共享表空间中。

4.支持外键：InnoDB支持外键约束，MyISAM不支持。

5.恢复：MyISAM支持将数据文件(.MYD)和索引文件(.MYI)拷贝到其他位置，然后使用这两个文件恢复数据。InnoDB则只能通过MySQL的数据恢复功能进行数据恢复。

6.全文索引：InnoDB在5.6之后的版本支持全文索引，而MyISAM一直支持。

7.空间和内存使用：InnoDB需要更多的磁盘空间和内存来保持性能。

如果你的应用需要高并发读写，那么InnoDB可能是更好的选择；而如果你的应用主要是读操作，并且需要全文索引，那么MyISAM可能是更好的选择。

再补充：聚簇索引和非聚簇索引的区别

聚簇索引：将数据存储与索引放到了一块，找到索引也就找到了数据
非聚簇索引：将数据存储于索引分开结构，索引结构的叶子节点指向了数据的对应行，myisam通过key_buffer把索引先缓存到内存中，当需要访问数据时（通过索引访问数据），在内存中直接搜索索引，然后通过索引找到磁盘相应数据，这也就是为什么索引不在key buffer命中时，速度慢的原因

InnoDB使用的是聚簇索引，将主键组织到一棵B+树中，而行数据就储存在叶子节点上，若使用"where id = 14"这样的条件查找主键，则按照B+树的检索算法即可查找到对应的叶节点，之后获得行数据

**若对Name列进行条件搜索，则需要两个步骤：**第一步在辅助索引B+树中检索Name，到达其叶子节点获取对应的主键。第二步使用主键在主索引B+树种再执行一次B+树检索操作，最终到达叶子节点即可获取整行数据。（重点在于通过其他键需要建立辅助索引）

聚簇索引和非聚簇索引的优缺点和使用场景

聚簇索引的优点：

查询效率高：由于聚簇索引的叶子节点存储了实际的数据行，相同索引值的数据行在物理上存储在相邻位置，可以减少磁盘IO，提高查询效率。
覆盖索引：如果查询只需要索引列的数据，聚簇索引可以满足覆盖索引的需求，避免了访问实际数据行的开销。

聚簇索引的缺点：

插入和更新的开销：由于数据行的物理存储顺序与聚簇索引的顺序相关，插入和更新数据可能导致数据移动和索引调整，造成一定的开销。
索引更新困难：当聚簇索引的键值发生变化时，需要对相关的数据行进行移动和索引更新，可能涉及大量的IO操作。
聚簇索引的应用场景：

经常需要按照某个特定的列进行范围查询或排序的情况。
需要快速获取覆盖索引的列数据的情况。

接下来，我们来看非聚簇索引的优点：

插入和更新的开销较低：由于非聚簇索引的叶子节点不存储实际的数据行，插入和更新数据只需要对索引进行调整，不会引起大量的数据移动和调整。
可以存在多个非聚簇索引：相对于聚簇索引，非聚簇索引可以根据不同的查询需求创建多个，更加灵活。

非聚簇索引的缺点：
查询涉及两次IO：首先通过非聚簇索引找到索引键值，然后再通过指针找到实际的数据行，涉及了两次IO操作，可能会降低查询效率。
不满足覆盖索引的需求：非聚簇索引的叶子节点不存储实际的数据行，无法满足某些查询需要覆盖索引的情况。
非聚簇索引的应用场景：

经常需要根据某个特定列进行查询的情况。
需要在一个表上创建多个索引以支持不同类型的查询的情况。

总体而言，聚簇索引适用于需要高效范围查询和排序的场景，而非聚簇索引适用于经常根据特定列进行查询的场景。在实际应用中，根据具体的业务需求和查询模式，选择合适的索引方式可以提高数据库的查询性能。

[lukaliou123]

13.SQL部分语法

left join
right join
inner join
cross join

Join和innerjoin,Union和unional

JOIN和INNER JOIN实际上是完全相同的。两者都是返回两个表中匹配的行。如果行在一个表中但不在另一个表中，则不返回该行。

而关于UNION和UNION ALL，这两个操作符都用于合并两个或多个SELECT查询的结果，但它们处理重复行的方式不同。

UNION操作符会合并查询结果并删除重复的行。结果集中的每一行都是唯一的。此外，UNION内部会进行排序，这可能会影响性能。

UNION ALL操作符合并查询结果，包括所有重复的行。相比之下，因为不需要进行额外的去重操作，UNION ALL通常会提供更好的性能。

所以简单来说，如果你不想在结果中有重复的行，你应该使用UNION。如果你不介意有重复的行，或者你知道结果集中不可能有重复的行，你应该使用UNION ALL。因为后者的性能更好。

[lukaliou123]

补充：SQL知识补充，有关数据库优化和索引

#20

补充:SQL知识补充，有关MVCC

#16

[lukaliou123]

14.MySQL的集群（搭建一般是运维做的）

MySQL集群部署可以有多种方式，常见的有主从复制（Master-Slave Replication）、主主复制（Master-Master Replication）以及MySQL Cluster等方式。
其中最基础的主从，是最常见的高可用解决方案，一般情况下，主服务器处理写操作，从服务器处理读操作，这样可以提高MySQL服务器的性能和数据可用性。
数据库的主从同步，就是为了要保证多个数据库之间的数据保持一致。如果要保证数据能够实时同步，对于MySQL，通常就要用到他自身提供的一套通过Binlog日志在多个MySQL服务之间进行同步的集群方案。基于这种集群方案，一方面可以提高数据的安全性，另外也可以以此为基础，提供读写分离、故障转移等其他高级的功能。

即在主库上打开Binlog日志，记录对数据的每一步操作。然后在从库上打开RelayLog日志，用来记录跟主库一样的Binlog日志，并将RelayLog中的操作日志在自己数据库中进行重演。这样就能够更加实时的保证主库与从库的数据一致。

MySQL的Binlog默认是不打开的。

他的实现过程是在从库上启动一系列IO线程，负责与主库建立TCP连接，请求主库在写入Binlog日志时，也往从库传输一份。这时，主库上会有一个IO Dump线程，负责将Binlog日志通过这些TCP连接传输给从库的IO线程。而从库为了保证日志接收的稳定性，并不会立即重演Binlog数据操作，而是先将接收到的Binlog日志写入到自己的RelayLog日志当中。然后再异步的重演RelayLog中的数据操作。

​ MySQL的BinLog日志能够比较实时的记录主库上的所有日志操作，因此他也被很多其他工具用来实时监控MySQL的数据变化。

15.bin-log是什么？

Binlog（Binary Log）是MySQL数据库提供的一种二进制日志文件。它记录了对数据库执行更改的所有语句，比如插入数据、更新数据或删除数据等操作。它的作用主要有以下几个方面：

1.数据恢复：如果数据库发生崩溃，可以通过重放Binlog日志来恢复数据。

2.主从复制：MySQL的主从复制就是通过复制并执行主服务器上的Binlog来同步数据的。

3.审计：通过分析Binlog可以查看数据库的变更历史，以进行审计。

因此，Binlog在MySQL数据库中起着非常重要的作用。但是需要注意的是，由于Binlog记录了大量的数据更改信息，所以他会随着数据库操作的增加而快速增大，需要定期清理以避免占用过多的磁盘空间

16.binlog和redolog的不同

1.记录的内容不同：Binlog是记录了所有修改数据的语句，它是逻辑日志，可以看到具体执行了哪些SQL。而Redo log是物理日志，记录的是对于页（Page）的物理修改。

2.记录的方式不同：Binlog是追加写入，即每次写入新的事件不会覆盖旧的事件，直到达到系统设置的上限，需要手动或自动进行清理。Redo log是循环写入，空间是固定的，写满后会从头开始覆盖使用。

3.使用的场景不同：Binlog主要用于MySQL的主从复制和数据恢复，可以实现点时间恢复。而Redo log是InnoDB存储引擎特有的，主要用于保证事务的持久性，宕机后能够按照Redo log的内容恢复数据。