Merge branch 'master' of github.com:heibaiying/Full-Stack-Notes

notes/MySQL_基础.md

@@ -45,6 +45,7 @@ InnoDB 是 MySQL 5.5 之后默认的存储引擎，它是一种兼具高可靠
 
 
 <div align="center"> <img src="https://github.com/heibaiying/Full-Stack-Notes/blob/master/pictures/innodb-architecture.png"/> </div>
+
 ### 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;
 **平衡二叉树数据结构**：
 
 <div align="center"> <img src="https://github.com/heibaiying/Full-Stack-Notes/blob/master/pictures/avl-tree.png"/> </div>
+
 **红黑树数据结构**：
 
 <div align="center"> <img src="https://github.com/heibaiying/Full-Stack-Notes/blob/master/pictures/red-black-tree.png"/> </div>
+
 **Btree 数据结构**：
 
 <div align="center"> <img src="https://github.com/heibaiying/Full-Stack-Notes/blob/master/pictures/btree.png"/> </div>
+
 **B+ Tree 数据结构**
 
 <div align="center"> <img src="https://github.com/heibaiying/Full-Stack-Notes/blob/master/pictures/B+Trees.png"/> </div>
@@ -281,21 +285,25 @@ InnoDB 存储引擎完全支持 ACID 模型：
 一个事务的更新操作被另外一个事务的更新操作锁覆盖，从而导致数据不一致：
 
 <div align="center"> <img src="https://github.com/heibaiying/Full-Stack-Notes/blob/master/pictures/mysql-修改丢失.png"/> </div>
+
 **2. 脏读**
 
 在不同的事务下，一个事务读取到其他事务未提交的数据：
 
 <div align="center"> <img src="https://github.com/heibaiying/Full-Stack-Notes/blob/master/pictures/mysql-脏读.png"/> </div>
+
 **3. 不可重复读**
 
 在同一个事务的两次读取之间，由于其他事务对数据进行了修改，导致对同一条数据两次读到的结果不一致：
 
 <div align="center"> <img src="https://github.com/heibaiying/Full-Stack-Notes/blob/master/pictures/mysql-不可重复读.png"/> </div>
+
 **4.幻读**
 
 在同一个事务的两次读取之间，由于其他事务对数据进行了修改，导致第二次读取到第一次不存在数据，或第一次原本存在的数据，第二次却读取不到，就好像之前的读取是 “幻觉” 一样：
 
 <div align="center"> <img src="https://github.com/heibaiying/Full-Stack-Notes/blob/master/pictures/mysql-幻读.png"/> </div>
+
 ### 4.4 隔离级别
 
 想要解决以上问题，可以通过设置隔离级别来实现：InnoDB 支持以下四个等级的隔离级别，默认隔离级别为可重复读：
@@ -330,11 +338,11 @@ InnoDB 存储引擎完全支持 ACID 模型：
 
 要求非主键列必须完全依赖于主键列，而不能存在部分依赖。示例如下：
 
-| mechanism_id （组织机构代码） | employee_id （雇员编号） | ename （雇员名称） | cname （组织机构名称） |
+| mechanism_id （组织机构代码） | employee_id （雇员编号） | ename （雇员名称） | mname （机构名称） |
-| ----------------------------- | ------------------------ | ------------------ | ---------------------- |
+| ----------------------------- | ------------------------ | ------------------ | ----------------|
-| 28193182                      | 10001                    | heibaiying         | XXXX公司               |
+| 28193182                      | 10001                    | heibaiying         | XXXX公司         |
 
-以上是一张全市在职人员统计表，主键为：机构编码 + 雇员编号，这里的雇员名称完全依赖于此联合主键，但机构名称就只依赖于机构代码，这就出现了部分依赖，违背了第二范式。此时最好的解决方式就是建立一张组织机构与组织名称的字典表。
+以上是一张全市在职人员统计表，主键为：机构编码 + 雇员编号。表中的雇员名称完全依赖于此联合主键，但机构名称却只依赖于机构编码，这就是部分依赖，因此违背了第二范式。此时常用的解决方式是建立一张组织机构与组织名称的字典表。
 
 #### 第三范式：避免传递依赖
 
@@ -344,7 +352,7 @@ InnoDB 存储引擎完全支持 ACID 模型：
 | ------------------------ | ------------------ | ------------------ | ----------------- |
 | 10001                    | heibaiying         | 06                 | 开发部            |
 
-这里还是一张雇员表，雇员名称和所属的部门编号都依赖于主键 employee_id ，但部门名称却依赖于部门编号，此时就出现了非主键列依赖于其他非主键列，这就违背的第三范式。此时最好的解决方式就是建立一张部门表用于维护部门相关的信息。
+以上是一张雇员表，雇员名称和所属的部门编号都依赖于主键 employee_id ，但部门名称却依赖于部门编号，此时就出现了非主键列依赖于其他非主键列，这就违背的第三范式。此时常用的解决方式是建立一张部门表用于维护部门相关的信息。
 
 #### 反范式设计
 

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)
++ [Percona XtraBackup - Documentation](https://www.percona.com/doc/percona-xtrabackup/LATEST/index.html)

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 高可用的架构示例图如下：
 
-<div align="center"> <img src="https://github.com/heibaiying/Full-Stack-Notes/blob/master/pictures/mysql-MMA架构.jpg"/> </div>
+<div align="center"> <img src="https://github.com/heibaiying/Full-Stack-Notes/blob/master/pictures/mysql-MMA架构.png"/> </div>
 
 MMM 架构的缺点在于虽然其能实现自动切换，但却不会主动补齐丢失的数据，所以会存在数据不一致性的风险。另外 MMM 的发布时间比较早，所以其也不支持 MySQL 最新的基于 GTID 的复制，如果你使用的是基于 GTID 的复制，则只能采用 MHA。
 
@@ -364,7 +364,7 @@ MMM 架构的缺点在于虽然其能实现自动切换，但却不会主动补
 
 MHA (Master High Availability) 是由 Perl 实现的一款高可用程序，相对于 MMM ，它能尽量避免数据不一致的问题。它监控的是一主多从的复制架构，架构如下图所示：
 
-<div align="center"> <img src="https://github.com/heibaiying/Full-Stack-Notes/blob/master/pictures/mysql-MHA架构.jpg"/> </div>
+<div align="center"> <img src="https://github.com/heibaiying/Full-Stack-Notes/blob/master/pictures/mysql-MHA架构.png"/> </div>
 
 在 Master 节点宕机后，其处理流程如下：