From bae615251348a91f48844796811c514ff555b042 Mon Sep 17 00:00:00 2001 From: CyC2018 <1029579233@qq.com> Date: Sat, 14 Apr 2018 21:49:39 +0800 Subject: [PATCH] auto commit --- notes/MySQL.md | 28 ++++++++++++++++------------ 1 file changed, 16 insertions(+), 12 deletions(-) diff --git a/notes/MySQL.md b/notes/MySQL.md index 176a1d88..56335138 100644 --- a/notes/MySQL.md +++ b/notes/MySQL.md @@ -40,7 +40,7 @@ InnoDB 是 MySQL 默认的事务型存储引擎，只有在需要 InnoDB 不支 ## MyISAM -提供了大量的特性，包括全文索引、压缩表、空间函数（GIS）等。应该注意的是，MySQL 5.6.4 添加了对 InnoDB 引擎的全文索引支持。 +提供了大量的特性，包括全文索引、压缩表、空间数据索引等。应该注意的是，MySQL 5.6.4 添加了对 InnoDB 引擎的全文索引支持。 不支持事务。 @@ -58,7 +58,7 @@ MyISAM 设计简单，数据以紧密格式存储。对于只读数据，或者 2. 备份：InnoDB 支持在线热备份。 3. 崩溃恢复：MyISAM 崩溃后发生损坏的概率比 InnoDB 高很多，而且恢复的速度也更慢。 4. 并发：MyISAM 只支持表级锁，而 InnoDB 还支持行级锁。 -5. 其它特性：MyISAM 支持压缩表和地理空间索引。 +5. 其它特性：MyISAM 支持压缩表和空间数据索引。 # 二、数据类型 @@ -142,12 +142,14 @@ InnoDB 引擎有一个特殊的功能叫“自适应哈希索引”，当某个 限制：哈希索引只包含哈希值和行指针，而不存储字段值，所以不能使用索引中的值来避免读取行。不过，访问内存中的行的速度很快，所以大部分情况下这一点对性能影响并不明显；无法用于分组与排序；只支持精确查找，无法用于部分查找和范围查找；如果哈希冲突很多，查找速度会变得很慢。 -### 3. 空间索引（R-Tree） +### 3. 空间数据索引（R-Tree） MyISAM 存储引擎支持空间索引，可以用于地理数据存储。 空间索引会从所有维度来索引数据，可以有效地使用任意维度来进行组合查询。 +必须使用 GIS 相关的函数来维护数据。 + ### 4. 全文索引 MyISAM 存储引擎支持全文索引，用于查找文本中的关键词，而不是直接比较索引中的值。 @@ -158,9 +160,9 @@ MyISAM 存储引擎支持全文索引，用于查找文本中的关键词，而 - 大大减少了服务器需要扫描的数据量； -- 帮助服务器避免进行排序和创建临时表； +- 帮助服务器避免进行排序和创建临时表（B+Tree 索引是有序的，可以用来做 ORDER BY 和 GROUP BY 操作）； -- 将随机 I/O 变为顺序 I/O。 +- 将随机 I/O 变为顺序 I/O（B+Tree 索引是有序的，也就将相关的列值都存储在一起）。 ## 索引优化 @@ -212,14 +214,14 @@ customer_id_selectivity: 0.0373 聚簇索引并不是一种索引类型，而是一种数据存储方式。 -术语“聚簇”表示数据行和相邻的键值紧密地存储在一起，InnoDB 的聚簇索引的数据行存放在 B+Tree 的叶子页中。 +术语“聚簇”表示数据行和相邻的键值紧密地存储在一起，InnoDB 的聚簇索引在同一个结构中保存了 B+Tree 索引和数据行。 因为无法把数据行存放在两个不同的地方，所以一个表只能有一个聚簇索引。 **优点** -1. 可以把相关数据保存在一起，减少 I/O 操作； -2. 因为数据保存在 B+Tree 中，因此数据访问更快。 +1. 可以把相关数据保存在一起，减少 I/O 操作。例如电子邮件表可以根据用户 ID 来聚集数据，这样只需要从磁盘读取少数的数据也就能获取某个用户的全部邮件，如果没有使用聚聚簇索引，则每封邮件都可能导致一次磁盘 I/O。 +2. 数据访问更快。 **缺点** @@ -245,15 +247,15 @@ customer_id_selectivity: 0.0373

-为了描述 B-Tree，首先定义一条数据记录为一个二元组 [key, data]，key 为记录的键，data 为数据记录除 key 外的数据。 +为了描述 B-Tree，首先定义一条数据记录为一个二元组 [key, data]。 B-Tree 是满足下列条件的数据结构： - 所有叶节点具有相同的深度，也就是说 B-Tree 是平衡的； - 一个节点中的 key 从左到右非递减排列； -- 如果某个指针的左右相邻 key 分别是 keyi 和 keyi+1，且不为 null，则该指针指向节点的所有 key 大于 keyi 且小于 keyi+1。 +- 如果某个指针的左右相邻 key 分别是 keyi 和 keyi+1，且不为 null，则该指针指向节点的所有 key 大于等于 keyi 且小于等于 keyi+1。 -在 B-Tree 中按 key 检索数据的算法非常直观：首先从根节点进行二分查找，如果找到则返回对应节点的 data，否则对相应区间的指针指向的节点递归进行查找，直到找到节点或找到 null 指针，前者查找成功，后者查找失败。 +在 B-Tree 中按 key 检索数据的算法非常直观：首先在根节点进行二分查找，如果找到则返回对应节点的 data，否则在相应区间的指针指向的节点递归进行查找。 由于插入删除新的数据记录会破坏 B-Tree 的性质，因此在插入删除时，需要对树进行一个分裂、合并、转移等操作以保持 B-Tree 性质。 @@ -278,7 +280,9 @@ B-Tree 是满足下列条件的数据结构： 页是计算机管理存储器的逻辑块，硬件及操作系统往往将主存和磁盘存储区分割为连续的大小相等的块，每个存储块称为一页（在许多操作系统中，页的大小通常为 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(logdN)。一般实际应用中，出度 d 是非常大的数字，通常超过 100，因此 h 非常小（通常不超过 3）。而红黑树这种结构，h 明显要深的多。并且于逻辑上很近的节点（父子）物理上可能很远，无法利用局部性，效率明显比 B-Tree 差很多。 B+Tree 更适合外存索引，原因和内节点出度 d 有关。由于 B+Tree 内节点去掉了 data 域，因此可以拥有更大的出度，拥有更好的性能。