MySQL存储引擎的常见问题

一. MySQL存储引擎的架构：

1. MySQL 存储引擎采用的是 插件式架构，支持多种存储引擎，我们甚至可以为不同的数据库表设置不同的存储引擎以适应不同场景的需要。
2. 存储引擎是基于表的，而不是数据库。
3. 可以根据 MySQL 定义的存储引擎实现标准接口编写第三方存储引擎，像目前最常用的 InnoDB 其实刚开始就是一个第三方存储引擎，后面由于过于优秀，其被 Oracle 直接收购了。

二. MyISAM 和 InnoDB 的区别是什么？

MySQL 【5.5】 之前，MyISAM 引擎是 MySQL 的默认存储引擎
由于MyISAM 不支持事务和行级锁，而且最大的缺陷就是崩溃后无法安全恢复。
MySQL 【5.5.5 】版本之后，InnoDB 是 MySQL 的默认存储引擎。

1. 是否支持行级锁

MyISAM 只有表级锁，而 InnoDB 支持行级锁和表级锁, 默认为行级锁。

表级锁：锁定粒度大，发生锁冲突的概率最高, 并发度最低
行级锁：即每次操作锁住对应的行数据，锁定粒度最小，发生锁冲突的概率最低，并发度最高 (DML默认开启行级锁)
也就说，MyISAM 一锁就是锁住了整张表 ！效率低下！

2. 是否支持事务

MyISAM 不提供事务支持。
InnoDB 提供事务支持，实现了 SQL 标准定义了四个隔离级别，具有提交(commit)和回滚(rollback)事务的能力。
并且，InnoDB 默认使用的 REPEATABLE-READ（可重复读）隔离级别。

3.是否支持外键

MyISAM 不支持，而 InnoDB 支持。
外键即子表引用父表，可以级联更新和删除，父表被引用的字段必须唯一；
外键对于维护数据一致性非常有帮助，但是对性能有一定的损耗。因此，通常情况下，我们是不建议在实际生产项目中使用外键的，在业务代码中进行约束即可！

4.是否支持数据库异常崩溃后的安全恢复

MyISAM 不支持，而 InnoDB 支持。
使用 InnoDB 的数据库在异常崩溃后，数据库重新启动的时候会保证数据库恢复到崩溃前的状态。这个恢复的过程依赖于 redo log 。

5.索引实现不一样

虽然 MyISAM 引擎和 InnoDB 引擎都是使用 B+Tree 作为索引结构，但是两者的实现方式不太一样。

InnoDB 引擎中，其数据文件本身就是索引文件，为聚簇索引；
而 MyISAM中，索引文件和数据文件是分离的，为非聚簇索引

6. 是否支持压缩

MyISAM 表支持数据压缩。压缩后表变成了只读表，提高了检索效率；
InnoDB不支持数据压缩

三. MyISAM 和 InnoDB 如何选择？

大多数时候使用的都是 InnoDB 存储引擎。
如果不在乎并发能力，也不需要事务支持，也不在乎崩溃后的安全恢复问题的话，选择 MyISAM 也是一个不错的选择，但是一般情况下，都需要考虑到这些问题的。

《MySQL 高性能》上面有一句话这样写到:
不要轻易相信“MyISAM 比 InnoDB 快”之类的经验之谈，这个结论往往不是绝对的。在很多我们已知场景中，InnoDB 的速度都可以让 MyISAM 望尘莫及，尤其是用到了聚簇索引，或者需要访问的数据都可以放入内存的应用。

补充：MEMORY存储引擎

查询最快，以前叫HEAP引擎；
其数据存储在内存中，且行的长度固定，这两个特点使得MEMORY存储引擎非常快。
MEMORY存储引擎使用表级锁；
缺点：不支持事务transactions、不支持回滚点Savepoints
所有数据和索引都存储在内存当中，不安全！
优点：查询速度最快！

应用场景：存储非永久需要的数据，或者是能够从基于磁盘的表中重新生成数据，查询速度最快！