InnoDB

innodb

InnoDB：支持事务安全的引擎，支持外键、行锁、事务是他的最大特点。如果有大量的update和insert，建议使用InnoDB，特别是针对多个并发和QPS较高的情况。

​ 1.Innodb是事务性数据库的首选引擎，支持ACID事物，支持行级锁定，高性能处理大量数据。

​ 2.Innodb给mysql提供了具有 ’事务、回滚和崩溃修复能力、多版本并发控制的事务安全型表。

我们可以吧Innodb的食物写入过程看成写作一篇文章的过程。Innodb的写入过程其实和我们写作的过程是非常类似的。

试想，领导让我们写一篇文章，发表在论坛上。然后我们想到了一个绝佳的电子，并决定要放到文章里，可是手上还有其他事情，一时半会儿写不完，又担心过后忘了，领导还等着我们回复，此时我们会怎么做吶？我们一定会先大概狗四个提纲，并把提纲和一些关键细节记录到本子上，作为草稿，然后立即告诉领导自己要写什么东西，让其确认。最后等晚上有时间了，再根据草稿去斟词酌句，编写正稿。

在这个过程中，我们用到的几个关键的东西：

​ 我们的大脑，用来临时暂时记住我们的电子

​ 草稿，我们需要草稿来保证不会把电子和关键的细节给忘了

​ 正稿，这是我们最终要输出的东西

​ 有了这几个东西，我们不仅能确保我们不会错过一片漂亮的文章，环能快速告诉领导自己一定可以搞定这件事情。

​ Innodb实际上也用到了这个关键的东西：

​ Buffer Pool:就是我们的大脑

​ 事物日志：就是我们的草稿

​ Datafile:就是我们的正稿

​ 只要按照之前写文章的过程，来进行整个事务的写入操作，不仅能保证不丢失数据，而且能够快速响应。

​ 一次写入操作试一次事务，Innodb首先八十五数据写入到Buffer Pool和事务日志中，也就是在大脑中记忆下来，并写下草稿。然后就可以提交事务，响应客户端了。之后innodb在“有时间的时候”，异步地 把这个写入的数据从Buffer Pool，或者事务日志中正式地写入到Datafile中，形成“正稿”。

其中，innodb为了保证事务日志这个“草稿”一定能无损地还原成正稿，还不能占用太多空间，事务日志还需要有一下特点：

​ 事务日志中一定保存了要写入的所有数据内容

​ 事务日志只会把新事物追加在日志最后，而不会在修改之前的内容

​ 一旦事物数据被写到datafile，事务日志中的“草稿”就可以删除了

​ 通过上面3个特点我们可以看出，在形成“正稿”之前，“草稿”是不会被删除的；同时，“草稿”的空间是可以被循环利用的，最后，只要“草稿”在，我们一定能写出“正稿”。

​ 这里我还需要证明的，是Recovery流程，也就是如果在形成“正稿”之前，数据库Crash了，我们需要重启整个过程，服务器，甚至只能把数据复制到另外一台服务器来进行恢复。这个时候，事物日志这个“草稿”就发挥了它最大的作用——数据恢复。这也和我们在工作生活中常出现的问题——把事情晚了——非常类似。

​ Budder Pool本质就是存储于内存中的一个数据结构，内存和人的大脑一样，是“健忘”的。数据库Crash时，Buffer Pool中的数据极大可能“灰飞烟灭”了。因此，事务日志就如我们贴心的“记事本”，它把我们的记忆，保存为“草稿”，当我们忘了的时候，就可以翻开，把记忆重新回想起来。

Innodb支持事务和行级锁，是innodb的最大特色。

事务的ACID属性：atomicity,consistent,isolation,durable。

并发事务带来的几个问题：更新丢失，脏读，不可重复读，幻读。

事务隔离级别：未提交读(Read uncommitted)，已提交读(Read committed)，可重复读(Repeatable read)，可序列化(Serializable)

四种隔离级别的比较

读数据一致性及并发副作用 隔离级别	读数据一致性	脏读	不可重复读	幻读
为提交读(read uncommitted)	最低级别，不读物理上顺坏的数据	是	是	是
已提交读(read committed)	语句级	否	是	是
可重复读(Repeatable red)	事务级	否	否	是
可序列化(Serializable)	最高级别，事务级	否	否	否

lizable) | 最高级别，事务级 | 否 | 否 | 否 |