auto commit

notes/MySQL.md

@@ -121,13 +121,17 @@ MySQL 提供了 FROM_UNIXTIME() 函数把 UNIX 时间戳转换为日期，并提
 
 ## 索引分类
 
-### 1. B-Tree 索引
+### 1. B+Tree 索引
 
-B-Tree 索引是大多数 MySQL 存储引擎的默认索引类型。
+<div align="center"> <img src="../pics//c23957e9-a572-44f8-be15-f306c8b92722.jpg"/> </div><br>
+
+《高性能 MySQL》一书使用 B-Tree 进行描述，其实从技术上来说这种索引是 B+Tree。
+
+B+Tree 索引是大多数 MySQL 存储引擎的默认索引类型。
 
 因为不再需要进行全表扫描，只需要对树进行搜索即可，因此查找速度快很多。
 
-可以指定多个列作为索引列，多个索引列共同组成键。B-Tree 索引适用于全键值、键值范围和键前缀查找，其中键前缀查找只适用于最左前缀查找。
+可以指定多个列作为索引列，多个索引列共同组成键。B+Tree 索引适用于全键值、键值范围和键前缀查找，其中键前缀查找只适用于最左前缀查找。
 
 除了用于查找，还可以用于排序和分组。
 
@@ -139,7 +143,7 @@ B-Tree 索引是大多数 MySQL 存储引擎的默认索引类型。
 
 在 MySQL 中只有 Memory 引擎显式支持哈希索引。
 
-InnoDB 引擎有一个特殊的功能叫“自适应哈希索引”，当某个索引值被使用的非常频繁时，会在 B-Tree 索引之上再创建一个哈希索引，这样就让 B-Tree 索引具有哈希索引的一些优点，比如快速的哈希查找。
+InnoDB 引擎有一个特殊的功能叫“自适应哈希索引”，当某个索引值被使用的非常频繁时，会在 B+Tree 索引之上再创建一个哈希索引，这样就让 B+Tree 索引具有哈希索引的一些优点，比如快速的哈希查找。
 
 限制：哈希索引只包含哈希值和行指针，而不存储字段值，所以不能使用索引中的值来避免读取行。不过，访问内存中的行的速度很快，所以大部分情况下这一点对性能影响并不明显；无法用于分组与排序；只支持精确查找，无法用于部分查找和范围查找；如果哈希冲突很多，查找速度会变得很慢。
 
@@ -179,7 +183,7 @@ SELECT actor_id FROM sakila.actor WHERE actor_id + 1 = 5;
 
 对于 BLOB、TEXT 和 VARCHAR 类型的列，必须使用前缀索引，只索引开始的部分字符。
 
-对于前缀长度的选取需要根据  **索引选择性**  来确定：不重复的索引值和记录总数的比值。选择性越高，查询效率也越高。最大值为 1 ，此时每个记录都有唯一的索引与其对应。
+对于前缀长度的选取需要根据  **索引选择性**  来确定：不重复的索引值和记录总数的比值。选择性越高，查询效率也越高。最大值为 1，此时每个记录都有唯一的索引与其对应。
 
 ### 3. 多列索引
 
@@ -209,7 +213,7 @@ customer_id_selectivity: 0.0373
 
 ### 5. 聚簇索引
 
-<div align="center"> <img src="../pics//b9e9ae8c-e216-4c01-b267-a50dbeb98fa4.jpg"/> </div><br>
+<div align="center"> <img src="../pics//e800b001-7779-495b-8459-d33a7440d7b8.jpg"/> </div><br>
 
 聚簇索引并不是一种索引类型，而是一种数据存储方式。
 
@@ -217,12 +221,12 @@ customer_id_selectivity: 0.0373
 
 因为无法把数据行存放在两个不同的地方，所以一个表只能有一个聚簇索引。
 
-#### 优点
+**优点** 
 
 1. 可以把相关数据保存在一起，减少 I/O 操作；
 2. 因为数据保存在 B-Tree 中，因此数据访问更快。
 
-#### 缺点
+**缺点** 
 
 1. 聚簇索引最大限度提高了 I/O 密集型应用的性能，但是如果数据全部放在内存，就没必要用聚簇索引。
 2. 插入速度严重依赖于插入顺序，按主键的顺序插入是最快的。
@@ -234,7 +238,7 @@ customer_id_selectivity: 0.0373
 
 索引包含所有需要查询的字段的值。
 
-#### 优点
+**优点** 
 
 1. 因为索引条目通常远小于数据行的大小，所以若只读取索引，能大大减少数据访问量。
 2. 一些存储引擎（例如 MyISAM）在内存中只缓存索引，而数据依赖于操作系统来缓存。因此，只访问索引可以不使用系统调用（通常比较费时）。
@@ -277,9 +281,9 @@ B-Tree 是满足下列条件的数据结构：
 
 红黑树等数据结构也可以用来实现索引，但是文件系统及数据库系统普遍采用 B-/+Tree 作为索引结构。
 
-页是计算机管理存储器的逻辑块，硬件及操作系统往往将主存和磁盘存储区分割为连续的大小相等的块，每个存储块称为一页（在许多操作系统中，页得大小通常为 4k），主存和磁盘以页为单位交换数据。
+页是计算机管理存储器的逻辑块，硬件及操作系统往往将主存和磁盘存储区分割为连续的大小相等的块，每个存储块称为一页（在许多操作系统中，页的大小通常为 4k），主存和磁盘以页为单位交换数据。
 
-一般来说，索引本身也很大，不可能全部存储在内存中，因此索引往往以索引文件的形式存储的磁盘上。为了减少磁盘 I/O，磁盘往往不是严格按需读取，而是每次都会预读。这样做的理论依据是计算机科学中著名的局部性原理：当一个数据被用到时，其附近的数据也通常会马上被使用。数据库系统的设计者巧妙利用了磁盘预读原理，将一个节点的大小设为等于一个页，这样每个节点只需要一次 I/O 就可以完全载入。B-Tree 中一次检索最多需要 h-1 次 I/O（根节点常驻内存），渐进复杂度为 O(h)=O(logdN)。一般实际应用中，出度 d 是非常大的数字，通常超过 100，因此 h 非常小（通常不超过 3）。而红黑树这种结构，h 明显要深的多。并且于逻辑上很近的节点（父子）物理上可能很远，无法利用局部性，效率明显比 B-Tree 差很多。
+一般来说，索引本身也很大，不可能全部存储在内存中，因此索引往往以索引文件的形式存储的磁盘上。为了减少磁盘 I/O，磁盘往往不是严格按需读取，而是每次都会预读。这样做的理论依据是计算机科学中著名的局部性原理：当一个数据被用到时，其附近的数据也通常会马上被使用。数据库系统的设计者巧妙利用了磁盘预读原理，将一个节点的大小设为等于一个页，这样每个节点只需要一次 I/O 就可以完全载入。B-Tree 中一次检索最多需要 h-1 次 I/O（根节点常驻内存），渐进复杂度为 O(h)=O(log<sub>d</sub>N)。一般实际应用中，出度 d 是非常大的数字，通常超过 100，因此 h 非常小（通常不超过 3）。而红黑树这种结构，h 明显要深的多。并且于逻辑上很近的节点（父子）物理上可能很远，无法利用局部性，效率明显比 B-Tree 差很多。
 
 B+Tree 更适合外存索引，原因和内节点出度 d 有关。由于 B+Tree 内节点去掉了 data 域，因此可以拥有更大的出度，拥有更好的性能。