1.InnoDB与MyISAM区别：

InnoDB 支持事务，MyISAM 不支持事务。这是 MySQL 将默认存储引擎从 MyISAM 变成 InnoDB 的重要原因之一；

InnoDB 支持外键，而 MyISAM 不支持。对一个包含外键的 InnoDB 表转为 MYISAM 会失败；

InnoDB 是聚集索引，MyISAM 是非聚集索引。

InnoDB 不保存表的具体行数，执行 select count(*) from table 时需要全表扫描。而MyISAM 用一个变量保存了整个表的行数，执行上述语句时只需要读出该变量即可，速度很快；

InnoDB 最小的锁粒度是行锁，MyISAM 最小的锁粒度是表锁。一个更新语句会锁住整张表，导致其他查询和更新都会被阻塞，因此并发访问受限。这也是 MySQL 将默认存储引擎从 MyISAM 变成 InnoDB 的重要原因之一；

(过时了)InnoDB不支持全文索引，而MyISAM支持全文索引，在涉及全文索引领域的查询效率上MyISAM速度更快；PS：Mysql5.7及以后版本的InnoDB支持全文索引了。

注： innoDB的辅助索引是通过辅助索引找到主键，再通过该主键到主键索引找到数据。

如何选择：

是否要支持事务，如果要请选择 InnoDB ，如果不需要可以考虑 MyISAM；

如果表中绝大多数都只是读查询，可以考虑 MyISAM，如果既有读也有写也挺频繁，请使用InnoDB；

系统奔溃后，MyISAM恢复起来更困难，能否接受，不能接受就选 InnoDB；

MySQL5.5版本开始Innodb已经成为Mysql的默认引擎(之前是MyISAM)，说明其优势是有目共睹的。如果你不知道用什么存储引擎，那就用InnoDB，至少不会差。

2.mysql 聚集索引和主键索引总结：

我们先了解下InnoDB引擎表的一些关键特征：InnoDB引擎表是基于B+树的索引组织表(IOT)。

每个表都需要有一个聚集索引(clustered index)；所有的行记录都存储在B+tree的叶子节点(leaf pages of the tree)；

基于聚集索引的增、删、改、查的效率相对是最高的；

如果我们定义了主键(PRIMARY KEY)，那么InnoDB会选择其作为聚集索引；

如果没有显式定义主键，则InnoDB会选择第一个不包含有NULL值的唯一索引作为主键索引；

如果也没有这样的唯一索引，则InnoDB会选择内置6字节长的ROWID作为隐含的聚集索引(ROWID随着行记录的写入而主键递增，这个ROWID不像ORACLE的ROWID那样可引用，是隐含的)。

综上总结，如果InnoDB表的数据写入顺序能和B+树索引的叶子节点顺序一致的话，这时候存取效率是最高的，也就是下面这几种情况的存取效率最高：

使用自增列(INT/BIGINT类型)做主键，这时候写入顺序是自增的，和B+数叶子节点分裂顺序一致；

如果该表不指定自增列做主键，同时也没有可以被选为主键的唯一索引(上面的条件)，这时候InnoDB会选择内置的ROWID作为主键，写入顺序和ROWID增长顺序一致；

如果一个InnoDB表又没有显示主键，又有可以被选择为主键的唯一索引，但该唯一索引可能不是递增关系时(例如字符串、UUID、多字段联合唯一索引的情况)，该表的存取效率就会比较差。

2.1 聚集索引 和 非聚集索引

聚集索引：将数据存储与索引放在一块，找到索引也就找到了数据。聚集索引表中存储的数据按照索引的顺序存储，检索效率比非聚集索引高，但对数据更新影响较大。(比如主键索引)

非聚集索引：将数据存储与索引分开。MyISAM通过key_buffer把索引先缓存在内存中，访问数据时，在内存中直接搜索索引，然后通过索引找到磁盘对应数据。 非聚集索引表示数据存储在一个地方，索引存储在另一个地方，索引带有指针指向行数据的存储位置。非聚集索引检索效率比聚集索引低，但对数据更新影响较小。

每个InnoDB表都有一个称为聚集索引的特殊索引，其中存储了行的数据。通常，聚集索引与主键索引同义。

mysql的innodb表，就是索引组织表，表中的所有数据行都放在索引上，这就约定了数据是严格按照顺序存放的，

聚集索引：叶子节点存的是整行数据，直接通过这个聚集索引的键值找到某行数据。

聚集索引：数据的物理存放顺序与索引顺序是一致的，即：只要索引是相邻的，那么对应的数据一定也是相邻地存放在磁盘上的。

聚集索引：数据行和相邻的键值紧凑地存储在一起，因为无法同时把数据行存放在两个不同的地方，所以一个表只能有一个聚集索引。

mysql的innodb表，其聚集索引相当于整张表，而整张表也是聚集索引。默认通过主键聚集数据，如果没有定义主键，则选择第一个非空的唯一索引，如果没有非空唯一索引，则选择rowid来作为聚集索引

mysql的innodb表，因为整张表也是聚集索引，select出来的结果是顺序排序的，比如主键字段的数据插入顺序可以是5、3、4、2、1,查询时不带order by得出的结果也是按1、2、3、4、5排序。

2.2 基于主键索引和非主键索引(二级索引或普通索引)的查询有什么区别？

主键索引的叶子节点存的是整行数据。在 InnoDB 里，主键索引也被称为聚集索引(clustered index)。非主键索引的叶子节点内容是主键的值。在 InnoDB 里，非主键索引也被称为二级索引(secondary index)。

如果语句是 select * from T where ID=500，即 主键查询方式，则只需要搜索 ID 这棵 B+树 ；

如果语句是 select * from T where k=5， 即 普通索引查询方式，则需要先搜索 k 索引树，得到 ID的值为 500，再到 ID 索引树搜索一次。这个过程称为回表。B+树为了维护索引有序性，在插入新值的时候需要做必要的维护。以上面为例，

如果插入新的行 ID 值为 700，则只只需要在 R5 的记录后面插入一个新记录。

如果新插入的 ID值为 400，就相对麻烦了，需要逻辑上挪动后面的数据，空出位置。

3. 什么是最左前缀原则?

最左前缀匹配原则：在MySQL建立联合索引时会遵守最左前缀匹配原则，即最左优先，在检索数据时从联合索引的最左边开始匹配。

由于在B+树结构的索引中，索引项是按照索引定义里面出现的字段顺序排序的，索引在查找的时候，可以快速定位到 ID 为 100的张一，然后直接向右遍历所有张开头的人，直到条件不满足为止。也就是说，当找到第一个满足条件的人之后，直接向右遍历就可以了，由于索引是有序的，所有满足条件的人都会聚集在一起。而这种定位到最左边，然后向右遍历寻找的方式，就是我们所说的最左前缀原则。

示例：一个(a,b,c)的组合索引。

通过a,c条件查询能不能使用或命中这个索引？-----能

通过b,c条件查询能不能使用或命中这个索引？-----不能

原因：索引文件具有B-Tree 的最左前缀匹配特性，如果左边的值未确定，那么无法使用此索引。

4.为什么用 B+ 树做索引而不用哈希表做索引?

哈希表是把索引字段映射成对应的哈希码然后再存放在对应的位置，这样的话，如果我们要进行模糊查找的话，显然哈希表这种结构是不支持的，只能遍历这个表。而B+树则可以通过最左前缀原则快速找到对应的数据。

如果我们要进行范围查找，例如查找ID为100 ~ 400的人，哈希表同样不支持，只能遍历全表。

索引字段通过哈希映射成哈希码，如果很多字段都刚好映射到相同值的哈希码的话，那么形成的索引结构将会是一条很长的链表，这样的话，查找的时间就会大大增加。

5.为什么建议使用主键自增的索引？

对于这棵主键索引的树：

如果插入 ID = 650 的一行数据，那么直接在最右边插入就可以了

但是如果插入的是 ID = 350 的一行数据，由于 B+ 树是有序的，那么需要将下面的叶子节点进行移动，腾出位置来插入 ID = 350 的数据，这样就会比较消耗时间。如果刚好 R4 所在的数据页已经满了，需要进行页分裂操作，这样会更加糟糕。

但是，如果主键是自增的，每次插入的 ID 都会比前面的大，那么每次只需要在后面插入就行， 不需要移动位置、页分裂等操作，这样可以提高性能。也就是为什么建议使用主键自增的索引。