一、MySQL存在的常用存储引擎
存储引擎就是指表的类型，数据库的存储引擎决定了表在计算机中的存储方式。
使用show engines; （show engines\G;）可查看数据库支持的存储引擎：
Engine ：表示存储引擎名称
Support ：说明MySQL是否支持该类引擎
Comment：表示对该引擎的评论
Transactions：表示是否支持事务处理
XA：表示是否分布式交易处理的XA规范
Savepoint：表示是否支持保存点
使用 show VARIABLES LIKE 'storage_engine';查看默认存储引擎（注意VARIABLES必须大写）
如果想更改默认的存储引擎，可以在my.ini中进行修改。将“default-storage-engine=INNODB” 更改为“default-storage-engine=MYISAN”，然后重启服务，修改则生效。
其中常用存储引擎有：MYISAM INNODB MEMORY
INNODB存储引擎
INNODB的索引：innodb采用B+树的存储结构。
是MySQL默认的存储引擎，具有事务特征，支持外键，支持自动增长列。
主键索引中，非叶子结点存储的是主键的关键字，叶子结点存储的是主键及其对应的记录的所有信息。
辅助索引中，非叶子结点存储的是关键字，叶子结点存储的是关键字及其对应的记录的主键值。
MYISAN存储引擎
MYISAN的索引：myisan的采用的是B+树来存储数据
不支持事务，不支持外键，其优势是访问速度块（不用回表）
myisan的主键索引中，非叶子结点存储的是主键的值，而叶子结点存储的是主键的关键字和该条记录在内存中的地址。
myisan的辅助索引和主键索引类似，非叶子结点只存储的是关键字，叶子结点上存储的关键字的该条记录在内存中的地址，在辅助索引中关键字是可以重复的，而主键索引不行。
myisan中存储的数据包含三部分： .frm （存储表的创建结构）
.MYD（存储表的数据）
.MYI（存储表的索引）
Memery的索引 :默认采用的是哈希结构存储（不适用于范围查询），其使用存储在内存中的内容来创建表，而且所有的内容也放到内存中，这与innodb和myisan存储引擎不同。
memery存储引擎包含一个文件：.frm（存储表的结构）
（数据文件都是存储在内存中，因此Memery类型的存储引擎访问比较快）
（ Hash索引底层是哈希表，哈希表是一种以key-value存储数据的结构，所以多个数据在存储关系上是完全没有任何顺序关系的，所以，对于区间查询是无法直接通过索引查询的，就需要全
表扫描。所以，哈希索引只适用于等值查询的场景）
MYSQL不同的存储引擎有哪些区别时？以下几点回答
-------------------------------------------------------------------------------------------------------------------------------------
种类 | 锁机制 | B-树索引 | 哈希索引 | 外键 | 事务 | 索引缓存 | 数据缓存
-------------------------------------------------------------------------------------------------------------------------------------
INNODB| 行锁 | 支持 | 不支持 | 支持 | 支持 | 支持 | 支持
-------------------------------------------------------------------------------------------------------------------------------------
MYISAM| 表锁 | 支持 | 不支持 | 不支持 | 不支持 | 支持 | 不支持
-------------------------------------------------------------------------------------------------------------------------------------
memory| 表锁 | 支持 | 支持 | 不支持 | 不支持 | 支持 | 支持
-------------------------------------------------------------------------------------------------------------------------------------
innodb
在InnoDB存储引擎中，也有页的概念，默认每个页的大小为16K，也就是每次读取数据时都是读取4*4k的大小！假设我们现在有一个用户表，我们往里面写数据
这里需要注意的一点是，在某个页内插入新行时，为了不减少数据的移动，通常是插入到当前行的后面或者是已删除行留下来的空间，所以在某一个页内的数据并不是完全有序的（后面页结构部分有细讲），但是为了为了数据访问顺序性，在每个记录中都有一个指向下一条记录的指针，以此构成了一条单向有序链表，不过在这里为了方便演示我是按顺序排列的！
由于数据还比较少，一个页就能容下，所以只有一个根结点，主键和数据也都是保存在根结点（左边的数字代表主键，右边名字、性别代表具体的数据）。假设我们写入10条数据之后，Page1满了，再写入新的数据会怎么存放呢？我们继续看下图
有个叫“秦寿生”的朋友来了，但是Page1已经放不下数据了，这时候就需要进行页分裂，产生一个新的Page。在innodb中的流程是怎么样的呢？
1、产生新的Page2，然后将Page1的内容复制到Page2。
2、产生新的Page3，“秦寿生”的数据放入Page3。
3、原来的Page1依然作为根结点，但是变成了一个不存放数据只存放索引的页，并且有两个子结点Page2、Page3。
这里有两个问题需要注意的是
1、为什么要复制Page1为Page2而不是创建一个新的页作为根结点，这样就少了一步复制的开销了？
如果是重新创建根结点，那根结点存储的物理地址可能经常会变，不利于查找。并且在innodb中根结点是会预读到内存中的，所以结点的物理地址固定会比较好！
2、原来Page1有10条数据，在插入第11条数据的时候进行裂变，根据前面对B-Tree、B+Tree特性的了解，那这至少是一颗11阶的树，裂变之后每个结点的元素至少为11/2=5个，那是不是应该页裂变之后主键1-5的数据还是在原来的页，主键6-11的数据会放到新的页，根结点存放主键6？
如果是这样的话新的页空间利用率只有50%，并且会导致更为频繁的页分裂。所以innodb对这一点做了优化，新的数据放入新创建的页，不移动原有页面的任何记录。
随着数据的不断写入，这棵树也逐渐枝繁叶茂，如下图
每次新增数据，都是将一个页写满，然后新创建一个页继续写，这里其实是有个隐含条件的，那就是主键自增！主键自增写入时新插入的数据不会影响到原有页，插入效率高！且页的利用率高！但是如果主键是无序的或者随机的，那每次的插入可能会导致原有页频繁的分裂，影响插入效率！降低页的利用率！这也是为什么在innodb中建议设置主键自增的原因！
这棵树的非叶子结点上存的都是主键，那如果一个表没有主键会怎么样？在innodb中，如果一个表没有主键，那默认会找建了唯一索引的列，如果也没有，则会生成一个隐形的字段作为主键！
有数据插入那就有删除，如果这个用户表频繁的插入和删除，那会导致数据页产生碎片，页的空间利用率低，还会导致树变的“虚高”，降低查询效率！这可以通过索引重建来消除碎片提高查询效率！
数据插入了怎么查找呢？
1、找到数据所在的页。这个查找过程就跟前面说到的B+Tree的搜索过程是一样的，从根结点开始查找一直到叶子结点。
2、在页内找具体的数据。读取第1步找到的叶子结点数据到内存中，然后通过分块查找的方法找到具体的数据。
这跟我们在新华字典中找某个汉字是一样的，先通过字典的索引定位到该汉字拼音所在的页，然后到指定的页找到具体的汉字。innodb中定位到页后用了哪种策略快速查找某个主键呢？这我们就需要从页结构开始了解。
左边蓝色区域称为Page Directory，这块区域由多个slot组成，是一个稀疏索引结构，即一个槽中可能属于多个记录，最少属于4条记录，最多属于8条记录。槽内的数据是有序存放的，所以当我们寻找一条数据的时候可以先在槽中通过二分法查找到一个大致的位置。
右边区域为数据区域，每一个数据页中都包含多条行数据。注意看图中最上面和最下面的两条特殊的行记录Infimum和Supremum，这是两个虚拟的行记录。在没有其他用户数据的时候Infimum的下一条记录的指针指向Supremum，当有用户数据的时候，Infimum的下一条记录的指针指向当前页中最小的用户记录，当前页中最大的用户记录的下一条记录的指针指向Supremum，至此整个页内的所有行记录形成一个单向链表。
行记录被Page Directory逻辑的分成了多个块，块与块之间是有序的，也就是说“4”这个槽指向的数据块内最大的行记录的主键都要比“8”这个槽指向的数据块内最小的行记录的主键要小。但是块内部的行记录不一定有序。
每个行记录的都有一个n_owned的区域（图中粉红色区域），n_owned标识这个这个块有多少条数据，伪记录Infimum的n_owned值总是1，记录Supremum的n_owned的取值范围为[1,8]，其他用户记录n_owned的取值范围[4,8]，并且只有每个块中最大的那条记录的n_owned才会有值，其他的用户记录的n_owned为0。
所以当我们要找主键为6的记录时，先通过二分法在稀疏索引中找到对应的槽，也就是Page Directory中“8”这个槽，“8”这个槽指向的是该数据块中最大的记录，而数据是单向链表结构所以无法逆向查找，所以需要找到上一个槽即“4”这个槽，然后通过“4”这个槽中最大的用户记录的指针沿着链表顺序查找到目标记录。
在 InnoDB 里，索引B+ Tree的叶子节点存储了整行数据的是主键索引。而索引B+ Tree的叶子节点存储了主键的值的是非主键索引。
前面关于数据存储的都是演示的主键索引的实现，如果上面的用户表需要以“用户名字”建立一个辅助索引，是怎么实现的呢？我们看下图：
非主键索引的存储结构与前面是一样的，不同的是在叶子结点的数据部分存的不再是具体的数据，而数据的主键索引的key。所以通过非主键索引查找的过程是先找到该索引key对应的主键索引的key，然后再拿主键索引的key到主键索引树上查找对应的数据，这个过程称为回表！
那么，主键索引和非主键索引，在查询数据的时候有区别吗？ 答：主键索引查询会更快，因为主键索引树的叶子节点直接就是我们要查询的整行数据了。而非主键索引的叶子节点是主键的值，查到主键的值以后，还需要再通过主键的值再到主键索引中再次进行查询，也就是回表。
聚集索引&非聚集索引
聚集索引是指数据库表中数据的物理顺序与键值的逻辑顺序相同。一个表只能有一个聚集索引，因为一个表的物理顺序只能有一个。一般主键索引默认为聚集索引。
非聚集索引是指数据库表中数据的物理顺序与键值的逻辑顺序不相同。一个表可以有多个非聚集索引。
上面的概念比较抽象不好理解，举一个新华字典的例子，在新华字典中的汉字都是按拼音从前到后存放的（物理顺序），想找“哎ai”字就在前面查找，想找“在zai”字就在后面查找。我们知道一般查找一个汉字有两种方法，一是按拼音表搜索，一种是按偏旁表搜索。其中按拼音表搜索就是聚集索引，因为汉字都是按拼音在字典中排列的，在拼音表中的顺序位置大致就是它具体的存储位置。而按偏旁表搜索就是非聚集索引，因为汉字在偏旁表中的顺序位置与它们在字典中存储的位置并不相同。
覆盖索引（如果索引包含所有满足查询-需要的-数据的-索引成为覆盖索引，也就是平时所说的不需要回表操作）
覆盖索引（covering index）指一个查询语句的执行只用从索引中就能够取得，不必从数据表中读取。也可以称之为实现了索引覆盖。 当一条查询语句符合覆盖索引条件时，MySQL只需要通过索引就可以返回查询所需要的数据，这样避免了查到索引后再返回表操作，减少I/O提高效率。 如，表student中有一个普通索引 idx_key1_key2(key1,key2)。当我们通过SQL语句：select key2 from student where key1 = 'keytest';的时候，就可以通过覆盖索引查询，无需回表。
5、如果要使用覆盖索引，一定要注意SELECT 列表值取出需要的列，不可以是SELECT *，因为如果将所有字段一起做索引会导致索引文件过大，查询性能下降，不能为了利用覆盖索引而这么做
innodb与MyISAM两种存储引擎对比
上面包括存储和搜索都是拿的innodb引擎为例，那MyISAM与innodb在存储上有啥不同呢？看图：
上图为MyISAM主键索引的存储结构，我们能看到的不同是
1、主键索引树的叶子结点的数据区域没有存放实际的数据，存放的是数据记录的地址。
2、数据的存储不是按主键顺序存放的，按写入的顺序存放。
也就是说innodb引擎数据在物理上是按主键顺序存放，而MyISAM引擎数据在物理上按插入的顺序存放。并且MyISAM的叶子结点不存放数据，所以非聚集索引的存储结构与聚集索引类似，在使用非聚集索引查找数据的时候通过非聚集索引树就能直接找到数据的地址了，不需要回表，这比innodb的搜索效率会更高呢！
本文摘自：https://www.cnblogs.com/sujing/