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) | 最高级别，事务级 | 否 | 否 | 否 |
