MySQL引擎之MyISAM，InnoDB，Btree与B+tree

Bertha 。 2023-10-05 18:12 14阅读 0赞

### 目录： ###

*  [MyISAM与InnoDB模块][MyISAM_InnoDB]
 *  [Btree模块][Btree]
 *  [B-tree与哈希索引的区别][B-tree]

## 一：MyISAM： ##

**创建一个myisam存储引擎的表的时候会出现三个文件**

*  tb\_demo.frm，存储表定义； 2.tb\_demo.MYD，存储数据； 3.tb\_demo.MYI，存储索引。
 *  因为MyISAM表有无法处理事务，所以它只适合在以下情况下使用
    
     *  1.选择密集型的表。MyISAM存储引擎在筛选大量数据时非常迅速，这是它最突出的优点。
     *  2.插入密集型的表。MyISAM的并发插入特性允许同时选择和插入数据。例如：MyISAM存储引擎很适合管理邮件或Web服务器日志数据。

## 二：InnoDB： ##

*  更新密集的表。InnoDB存储引擎特别适合处理多重并发的更新请求。
 *  事务。InnoDB存储引擎是支持事务的标准MySQL存储引擎。
 *  自动灾难恢复。与其它存储引擎不同，InnoDB表能够自动从灾难中恢复。
 *  外键约束。MySQL支持外键的存储引擎只有InnoDB。
 *  支持自动增加列AUTO\_INCREMENT属性。

## 三. Innodb与MyIASM引擎的区别与应用场景 ##

### 1. Innodb与MyIASM引擎的区别 ###

**(1)事务处理：**

*  MyIASM是非事务安全型的，而InnoDB是事务安全型的（支持事务处理等高级处理）；

**(2)锁机制不同：**

*  MyIASM是表级锁，而InnoDB是行级锁；

**(3)select ,update ,insert ,delete 操作：**

*  MyIASM：如果执行大量的SELECT，MyISAM是更好的选择。
 *  InnoDB：如果你的数据执行大量的INSERT或UPDATE，出于性能方面的考虑，应该使用InnoDB表。

**(4)查询表的行数不同：**

*  MyIASM：select count() from table,MyISAM只要简单的读出保存好的行数，注意的是，当count()语句包含 where条件时，两种表的操作是一样的。
 *  InnoDB ： InnoDB 中不保存表的具体行数，也就是说，执行select count(\*) from table时，InnoDB要扫描一遍整个表来计算有多少行。

**(5)外键支持：**

*  mysiam表不支持外键，而InnoDB支持。

### 2.为什么MyIASM会比Innodb 的查询速度快 ###

*  InnoDB在做SELECT的时候，要维护的东西比MyIASM引擎多很多；
 *  数据块，INNODB要缓存，MyIASM只缓存索引块， 这中间还有换进换出的减少；
 *  innodb寻址要映射到块，再到行，MyIASM记录的直接是文件的OFFSET，定位比INNODB要快；
 *  INNODB还需要维护MVCC一致；虽然你的场景没有，但他还是需要去检查和维护。
 *  MVCC ( Multi-Version Concurrency Control )多版本并发控制 。

**应用场景：**

*  MyIASM适合：(1)做很多count 的计算；(2)插入不频繁，查询非常频繁；(3)没有事务。
 *  InnoDB适合：(1)可靠性要求比较高，或者要求事务；(2)表更新和查询都相当的频繁，并且行锁定的机会比较大的情况。

## 四. Btree与b+tree ##

### 1. Btree： ###

*  B-tree是一种多路自平衡搜索树，它类似普通的二叉树，但是Btree允许每个节点有更多的子节点。Btree示意图如下：  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xvbmdsb25nNjY4Mg_size_16_color_FFFFFF_t_70]
 *  B树的搜索，从根结点开始，如果查询的关键字与结点的关键字相等，那么就命中；否则，如果查询关键字比结点关键字小，就进入左儿子；如果比结点关键字大，就进入右儿子；如果左儿子或右儿子的指针为空，则报告找不到相应的关键字；
 *  如果B树的所有非叶子结点的左右子树的结点数目均保持差不多（平衡），那么B树的搜索性能逼近二分查找；但它比连续内存空间的二分查找的优点是，改变B树结构（插入与删除结点）不需要移动大段的内存数据，甚至通常是常数开销；
 *  右边也是一个B树，但它的搜索性能已经是线性的了；同样的关键字集合有可能导致不同的树结构索引；所以，使用B树还要考虑尽可能让B树保持左图的结构，和避免右图的结构，也就是所谓的“平衡”问题；
 *  实际使用的B树都是在原B树的基础上加上平衡算法，即“平衡二叉树”；如何保持B树结点分布均匀的平衡算法是平衡二叉树的关键；平衡算法是一种在B树中插入和删除结点的策略；

### 由上图可知 Btree 的一些特点: ###

*  所有键值分布在整个树中
 *  任何关键字出现且只出现在一个节点中
 *  搜索有可能在非叶子节点结束
 *  在关键字全集内做一次查找，性能逼近二分查找算法

### 2. B+tree： ###

**B+tree是Btree的变体，也是一种多路搜索树：**

1.其定义基本与B-树同，除了：
    
       2.非叶子结点的子树指针与关键字个数相同；
    
       3.非叶子结点的子树指针P[i]，指向关键字值属于[K[i], K[i+1])的子树（B-树是开区间）；
    
       5.为所有叶子结点增加一个链指针；
    
       6.所有关键字都在叶子结点出现；

*  1
 *  2
 *  3
 *  4
 *  5
 *  6
 *  7
 *  8
 *  9

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xvbmdsb25nNjY4Mg_size_16_color_FFFFFF_t_70 1]

*  B+的搜索与B-树也基本相同，区别是B+树只有达到叶子结点才命中（B-树可以在非叶子结点命中），其性能也等价于在关键字全集做一次二分查找；

**B+tree的特性：**

1.所有关键字都出现在叶子结点的链表中（稠密索引），且链表中的关键字恰好是有序的；
    
       2.不可能在非叶子结点命中；
    
       3.非叶子结点相当于是叶子结点的索引（稀疏索引），叶子结点相当于是存储（关键字）数据的数据层；
    
       4.更适合文件索引系统；

*  1
 *  2
 *  3
 *  4
 *  5
 *  6
 *  7

### btree和B+tree的区别： ###

*  (1)B+tree的非叶子节点不存储真正的data，而btree可以
 *  (2)增加了一个链指针
 *  (3)btree支持数据的延展性，B+tree支持数据的扩展性

## B\*Tree： ##

**是B+树的变体，在B+树的非根和非叶子结点再增加指向兄弟的指针；**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xvbmdsb25nNjY4Mg_size_16_color_FFFFFF_t_70 2]

*  B\*树定义了非叶子结点关键字个数至少为(2/3)\*M，即块的最低使用率为2/3（代替B+树的1/2）；
 *  B+树的分裂：当一个结点满时，分配一个新的结点，并将原结点中1/2的数据复制到新结点，最后在父结点中增加新结点的指针；B+树的分裂只影响原结点和父结点，而不会影响兄弟结点，所以它不需要指向兄弟的指针；
 *  B\*树的分裂：当一个结点满时，如果它的下一个兄弟结点未满，那么将一部分数据移到兄弟结点中，再在原结点插入关键字，最后修改父结点中兄弟结点的关键字（因为兄弟结点的关键字范围改变了）；如果兄弟也满了，则在原结点与兄弟结点之间增加新结点，并各复制1/3的数据到新结点，最后在父结点增加新结点的指针；
 *  所以，B\*树分配新结点的概率比B+树要低，空间使用率更高；

## 三. B-tree与哈希索引的区别 ##

### 1）B+tree的索引： ###

*  是按照顺序存储的，所以，如果按照B+tree索引，可以直接返回，带顺序的数据，但这个数据只是该索引列含有的信息。因此是顺序I/O
 *  适用于： 精确匹配 、范围匹配 、最左匹配

### 2）Hash索引： ###

*  索引列值的哈希值+数据行指针：因此找到后还需要根据指针去找数据，造成随机I/O
 *  适合： 精确匹配
 *  不适合： 模糊匹配 、范围匹配 、不能排序

来源：[https://blog.csdn.net/longlong6682/article/details/104805941][https_blog.csdn.net_longlong6682_article_details_104805941]

[MyISAM_InnoDB]: https://blog.csdn.net/longlong6682/article/details/104805941#a
[Btree]: https://blog.csdn.net/longlong6682/article/details/104805941#b
[B-tree]: https://blog.csdn.net/longlong6682/article/details/104805941#f
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xvbmdsb25nNjY4Mg_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200316204326961.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xvbmdsb25nNjY4Mg==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xvbmdsb25nNjY4Mg_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/2020031121565145.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xvbmdsb25nNjY4Mg==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xvbmdsb25nNjY4Mg_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20200311215842922.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xvbmdsb25nNjY4Mg==,size_16,color_FFFFFF,t_70
[https_blog.csdn.net_longlong6682_article_details_104805941]: https://blog.csdn.net/longlong6682/article/details/104805941