Update MySQL_基础.md

notes/MySQL_基础.md

@@ -76,7 +76,7 @@ CSV 存储引擎使用逗号分隔值的格式将数据存储在文本文件中
 
 ### 1.5 ARCHIVE
 
-ARCHIVE 存储引擎默认采用 zlib 无损数据压缩算法进行数据压缩，能够利用极小的空间存储大量的数据。创建ARCHIVE 表时，存储引擎会创建与表同名的 `ARZ` 文件，用于存储数据。它还具有以下特点：
+ARCHIVE 存储引擎默认采用 zlib 无损数据压缩算法进行数据压缩，能够利用极小的空间存储大量的数据。创建 ARCHIVE 表时，存储引擎会创建与表同名的 `ARZ` 文件，用于存储数据。它还具有以下特点：
 
 + ARCHIVE 引擎支持 INSERT，REPLACE 和 SELECT，但不支持 DELETE 或 UPDATE。
 + ARCHIVE 引擎支持 AUTO_INCREMENT 属性，并支持在其对应的列上建立索引，如果尝试在不具有 AUTO_INCREMENT 属性的列上建立索引，则会抛出异常。
@@ -137,8 +137,8 @@ mysql>  SELECT * FROM total;
 
 从上面的图示中我们可以看出 B+ Tree 树具有以下优点：
 
-+ B+ Tree 树的所有非叶子节点 (如 003，007)，都会在叶子节点冗余一份，所有叶子节点都按照链表的方式进行组织，这样带来的好处是在范围查询中，只需要通过遍历叶子节点就可以获取到所有的索引信息。
-+ B+ Tree 的所有非叶子节点都可以存储多个数据值，这取决于节点的大小，在 MySQL 中每个节点的大小为 16K ，因此其具备更大的出度，即在相同的数据量下，其树的高度更低。
++ B+ Tree 树的所有非叶子节点 (如 003，007)，都会在叶子节点冗余一份，所有叶子节点按照链表的方式进行组织，这样带来的好处是在范围查询中，只需要通过遍历叶子节点就可以获取到所有的索引信息。
++ B+ Tree 的所有非叶子节点都可以存储多个数据值，存储量取决于节点的大小，在 MySQL 中每个节点的大小为 16K ，因此其具备更大的出度，即在相同的数据量下，其树的高度更低。
 + 所有非叶子节点都只存储索引值，不存储实际的数据，只有叶子节点才会存储指针信息或数据信息。按照每个节点为 16K 的大小计算，对于千万级别的数据，其树的高度通常都在 3~6 左右 (取决于索引值的字节数)，因此其查询性能非常优异。
 + 叶子节点存储的数据取决于不同数据库的实现，对于 MySQL 来说，取决于使用的存储引擎和是否是主键索引。
 
@@ -156,12 +156,12 @@ mysql>  SELECT * FROM total;
 + **前缀匹配**：以联合索引的前缀为查找条件。如 `emp_no` 和 `dept_no` 为联合索引，查找条件为  `emp_no = 10008`。
 + **列前缀匹配**：匹配索引列的值的开头部分。如 `dept_no` 为索引，查询条件为  `dept_no like "d1%"`。前缀匹配和列前缀匹配都是索引前缀性的体现，在某些时候也称为前缀索引。
 + **匹配范围值**：按照索引列匹配一定范围内的值。如 `emp_no` 字段为索引，查询条件为  `emp_no > 10008`。
-+ **只访问索引的查询**：如 `emp_no` 字段为索引，查询语句为  `select emp_no from employees`，此时 emp_no 索引被称为本次查询的覆盖索引，即只需要从索引上就可以获取全部的查询信息，而不必访问实际的表中的数据。
++ **只访问索引的查询**：如 `emp_no` 字段为索引，查询语句为  `select emp_no from employees`，此时 emp_no 索引被称为本次查询的覆盖索引，即只需要从索引上就可以获取全部的查询信息，而不必访问实际表中的数据。
 + **精确匹配某一列并范围匹配某一列**：如 `emp_no` 和 `dept_no` 为联合索引，查找条件为  `dept_no = "d004" and emp_no < 10020`，这种情况下索引顺序可以是（emp_no, dept_no），也可以是（dept_no, emp_no），使用 EXPLAIN 来分析的话，其 TYPE 类型都是 range（使用索引进行范围扫描），但（dept_no, emp_no）性能更好。
 
 ### 2.3 哈希索引
 
-使用哈希索引时，存储引擎会对索引列的值进行哈希运算，并将计算出的哈希值和指向该行数据的指针存储在索引中，因此它更适用于等值比较查询，而不是范围查询，同样也不能用于优化排序和分组等操作。在建立哈希索引时，需要选取选择性比较高的列，即列上的数据不容易重复 (如身份证号)，这样可以尽量避免哈希冲突。因为哈希索引并不需要存储索引列的数据，所以其结构比较紧凑，对应的查询速度也比较快。
+使用哈希索引时，存储引擎会对索引列的值进行哈希运算，并将计算出的哈希值和指向该行数据的指针存储在索引中，因此它更适用于等值查询，而不是范围查询，同样也不能用于优化排序和分组等操作。在建立哈希索引时，需要选取选择性比较高的列，即列上的数据不容易重复 (如身份证号)，这样可以尽量避免哈希冲突。因为哈希索引并不需要存储索引列的数据，所以其结构比较紧凑，对应的查询速度也比较快。
 
 InnoDB 引擎有一个名为 “自适应哈希索引 (adaptive hash index)” 的功能，当某些索引值被频繁使用时，它会在内存中基于 B+ tree 索引再创建一个哈希索引，从而让 B-Tree 索引具备哈希索引快速查找的优点。
 
@@ -325,7 +325,7 @@ InnoDB 存储引擎完全支持 ACID 模型：
 | 可重复读（REPEATABLE READ）  | 不可能     | 不可能     | 可能   |
 | 串行化（SERIALIZABLE）       | 不可能     | 不可能     | 不可能 |
 
-就数据库层面而言，当前任何隔离级别下都不会发生丢失更新的问题，以 InnoDB 存储引擎为例，如果你想要更改表中某行数据，该行数据上必然会加上 X 锁，而对应的表上则会加上 IX 锁，其他任何事务必须等待获取该锁才能进行修改操作。
+就数据库层面而言，当前任何隔离级别下都不会发生丢失更新的问题，以 InnoDB 存储引擎为例，如果你想要更改表中某行数据，该行数据上必然会加上 X 锁，而对应的表上则会加上 IX 锁，其他任何事务都必须等待获取该锁才能进行修改操作。