diff --git a/notes/MySQL_基础.md b/notes/MySQL_基础.md
index 6bbed20..e971e6d 100644
--- a/notes/MySQL_基础.md
+++ b/notes/MySQL_基础.md
@@ -45,6 +45,7 @@ InnoDB 是 MySQL 5.5 之后默认的存储引擎，它是一种兼具高可靠
+
### 1.2 MyISAM
MyISAM 是 MySQL 5.5 之前默认的存储引擎。创建 MyISAM 表时会创建两个同名的文件：
@@ -52,7 +53,7 @@ MyISAM 是 MySQL 5.5 之前默认的存储引擎。创建 MyISAM 表时会创建
+ 扩展名为 `.MYD`（`MYData`）：用于存储表数据；
+ 扩展名为 `.MYI` （`MYIndex`）： 用于存储表的索引信息。
-在 MySQL 8.0 之后，只会创建上述两个同名文件，因为在该版本中表结构的定义存储在 MySQL 数据字典中，但在 MySQL 8.0 之前，还会存在一个扩展名为 `.frm` 的扩展文件，用于存储表结构信息。MyISAM 与 InnoDB 主要的区别其只支持表级锁，不支持行级锁，不支持事务，不支持自动崩溃恢复，但可以使用内置的 mysqlcheck 和 myisamchk 工具来进行检查和修复。
+在 MySQL 8.0 之后，只会创建上述两个同名文件，因为在该版本中表结构的定义存储在 MySQL 数据字典中，但在 MySQL 8.0 之前，还会存在一个扩展名为 `.frm` 的文件，用于存储表结构信息。MyISAM 与 InnoDB 主要的区别其只支持表级锁，不支持行级锁，不支持事务，不支持自动崩溃恢复，但可以使用内置的 mysqlcheck 和 myisamchk 工具来进行检查和修复。
### 1.3 MEMORY
@@ -119,12 +120,15 @@ mysql> SELECT * FROM total;
**平衡二叉树数据结构**：
+
**红黑树数据结构**：
+
**Btree 数据结构**：
+
**B+ Tree 数据结构**
@@ -281,21 +285,25 @@ InnoDB 存储引擎完全支持 ACID 模型：
一个事务的更新操作被另外一个事务的更新操作锁覆盖，从而导致数据不一致：
+
**2. 脏读**
在不同的事务下，一个事务读取到其他事务未提交的数据：
+
**3. 不可重复读**
在同一个事务的两次读取之间，由于其他事务对数据进行了修改，导致对同一条数据两次读到的结果不一致：
+
**4.幻读**
在同一个事务的两次读取之间，由于其他事务对数据进行了修改，导致第二次读取到第一次不存在数据，或第一次原本存在的数据，第二次却读取不到，就好像之前的读取是 “幻觉” 一样：
+
### 4.4 隔离级别
想要解决以上问题，可以通过设置隔离级别来实现：InnoDB 支持以下四个等级的隔离级别，默认隔离级别为可重复读：
@@ -330,11 +338,11 @@ InnoDB 存储引擎完全支持 ACID 模型：
要求非主键列必须完全依赖于主键列，而不能存在部分依赖。示例如下：
-| mechanism_id （组织机构代码） | employee_id （雇员编号） | ename （雇员名称） | cname （组织机构名称） |
-| ----------------------------- | ------------------------ | ------------------ | ---------------------- |
-| 28193182 | 10001 | heibaiying | XXXX公司 |
+| mechanism_id （组织机构代码） | employee_id （雇员编号） | ename （雇员名称） | mname （机构名称） |
+| ----------------------------- | ------------------------ | ------------------ | ----------------|
+| 28193182 | 10001 | heibaiying | XXXX公司 |
-以上是一张全市在职人员统计表，主键为：机构编码 + 雇员编号，这里的雇员名称完全依赖于此联合主键，但机构名称就只依赖于机构代码，这就出现了部分依赖，违背了第二范式。此时最好的解决方式就是建立一张组织机构与组织名称的字典表。
+以上是一张全市在职人员统计表，主键为：机构编码 + 雇员编号。表中的雇员名称完全依赖于此联合主键，但机构名称却只依赖于机构编码，这就是部分依赖，因此违背了第二范式。此时常用的解决方式是建立一张组织机构与组织名称的字典表。
#### 第三范式：避免传递依赖
@@ -344,7 +352,7 @@ InnoDB 存储引擎完全支持 ACID 模型：
| ------------------------ | ------------------ | ------------------ | ----------------- |
| 10001 | heibaiying | 06 | 开发部 |
-这里还是一张雇员表，雇员名称和所属的部门编号都依赖于主键 employee_id ，但部门名称却依赖于部门编号，此时就出现了非主键列依赖于其他非主键列，这就违背的第三范式。此时最好的解决方式就是建立一张部门表用于维护部门相关的信息。
+以上是一张雇员表，雇员名称和所属的部门编号都依赖于主键 employee_id ，但部门名称却依赖于部门编号，此时就出现了非主键列依赖于其他非主键列，这就违背的第三范式。此时常用的解决方式是建立一张部门表用于维护部门相关的信息。
#### 反范式设计
diff --git a/notes/MySQL_备份.md b/notes/MySQL_备份.md
index de307f7..dd2dc19 100644
--- a/notes/MySQL_备份.md
+++ b/notes/MySQL_备份.md
@@ -65,11 +65,11 @@ mysqldump [options] --all-databases
options 代表可选操作，常用的可选参数如下：
+ **--host=host_name， -h host_name**
-
+
指定服务器地址。
+ **--user=user_name， -u user_name**
-
+
指定用户名。
+ **--password[=password]， -p[password]**
@@ -201,7 +201,7 @@ mysqlpump 在 mysqldump 的基础上进行了扩展增强，其主要的优点
- 能够直接对备份文件进行压缩；
- 备份时能够显示进度指标（估计值）；
-- 备份用户时生成的是 CREATE USER 与 GRANT 语句，而不是像 mysqldump 一样直接备份成数据，可以方便用户按需恢复。
+- 备份用户时生成的是 CREATE USER 与 GRANT 语句，而不是像 mysqldump 一样备份成数据，可以方便用户按需恢复。
### 3.2 常用参数
@@ -379,4 +379,4 @@ mysqlbinlog --read-from-remote-server --raw --stop-never \
+ [Chapter 7 Backup and Recovery](https://dev.mysql.com/doc/refman/8.0/en/backup-and-recovery.html)
+ [mysqldump — A Database Backup Program](https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html)
+ [mysqlpump — A Database Backup Program](https://dev.mysql.com/doc/refman/8.0/en/mysqlpump.html)
-+ [Percona XtraBackup - Documentation](https://www.percona.com/doc/percona-xtrabackup/LATEST/index.html)
\ No newline at end of file
++ [Percona XtraBackup - Documentation](https://www.percona.com/doc/percona-xtrabackup/LATEST/index.html)
diff --git a/notes/MySQL_复制.md b/notes/MySQL_复制.md
index cc39e9c..f5f25e2 100644
--- a/notes/MySQL_复制.md
+++ b/notes/MySQL_复制.md
@@ -123,7 +123,7 @@ CHANGE MASTER TO MASTER_HOST='192.168.0.226',\
START SLAVE;
```
-查看从节点复制状态，主要参数有 Slave_IO_Running 和 Slave_SQL_Running，其状态都为 Yes 表示用于进行复制的 IO 进程已经开启。Seconds_Behind_Master 参数表示从节点复制的延迟量。此时可以在主库上进行任意更改，并在备库上查看情况。
+查看从节点复制状态，主要参数有 Slave_IO_Running 和 Slave_SQL_Running，其状态都为 Yes 表示用于复制的 IO 进程已经开启。Seconds_Behind_Master 参数表示从节点复制的延迟量。此时可以在主库上进行任意更改，并在备库上查看情况。
```shell
mysql> SHOW SLAVE STATUS\G
@@ -356,7 +356,7 @@ MMM (Master-Master replication manager for MySQL) 是由 Perl 语言开发的一
除了管理双主节点，MMM 也负责管理所有 Slave节点，在出现宕机、复制延迟或复制错误，MMM 会移除该节点的 VIP，直至节点恢复正常。MMM 高可用的架构示例图如下：
-
+
MMM 架构的缺点在于虽然其能实现自动切换，但却不会主动补齐丢失的数据，所以会存在数据不一致性的风险。另外 MMM 的发布时间比较早，所以其也不支持 MySQL 最新的基于 GTID 的复制，如果你使用的是基于 GTID 的复制，则只能采用 MHA。
@@ -364,7 +364,7 @@ MMM 架构的缺点在于虽然其能实现自动切换，但却不会主动补
MHA (Master High Availability) 是由 Perl 实现的一款高可用程序，相对于 MMM ，它能尽量避免数据不一致的问题。它监控的是一主多从的复制架构，架构如下图所示：
-
+
在 Master 节点宕机后，其处理流程如下：
