关键词： 结构。 特性， redo undo , 事务，索引。
1。 后台线程
1） 主线程： 缓冲池数据 异步刷新到磁盘（脏页， 插入缓存）undo页的回收等
2） IO线程： innodb会利用AIO 写IO请求。 线程负责处理这些线程的回调。
3） purge线程：， undo页的回收
4）page clearner thread: 将之前版本中脏页刷新到磁盘。
2。特性
1）插入缓冲： 由于聚集索引都是 大多连续的写，性能就不错， 但是 非聚集索引 (需要非唯一)确是 分散的写入，所以为了性能就有了插入缓冲池（不会超过缓冲池的1/2）
2）double Write: 两次写，保障数据安全，对于数据写中断， 脏页刷盘的时候 一个page写了一半， 那么 这个页面 headsum 和 tailsum是 验证不通过，是损坏的页面。
而且这个页面通过 redo log 是恢复不了的。 redo log 是 页的物理 逻辑日志， 所以需要有人 配合它 -> double write
3） 异步IO ： IO合并， 以及 提高磁盘操作 性能。
4） 刷新临界： 刷脏页的时候 会吧整个区的页 也 都看下， 是否要刷新 [ 固态 并不是特别需要， 可能写的页不怎么脏 ]
3：锁
1) lock 和 latch区别？
lock -> 事物， latch统资源锁定， 轻锁， 要求短时间释放。
2) 解决幻读： 在 REPEATABLE READ 解决了幻读问题， 得意于 其Next-key Lock 区间锁。 也就是说区间统计时 会有区间锁定。
3）MVCC: 在 A事物对行进行更新时会有 排它锁， 因此其他事物读取的时候其实读取的是 undo log的快照， 因为 不能读取未提交的数据。 要注意的是， 如果A，B 同时 开始事物，A提交后。 没有幻读问题。
4：事物
原子性: 一个操作只有 两个 状态 成功 or 失败？ 不会 出现一部分数据 更新成功
一致性：一个事务吧数据从A状态变成B状态， 不会改变数据库的完整性 约束， 比如说 银行转帐 后总存款， 和 唯一索引。
隔离性： 每个事务的 读写事物对象 对 其他事物隔离。
持久性： 一旦提交，就是永久的 不会出现断电了 回复不了（刷盘不同步问题）。
1) 脏读 ： 读取到了未 提交的脏数据， 可能回滚。
2）不可重复读 : 其可以读取别人 提交的数据 可能导致两次的读取结果不一样。
3) 幻读 ： 我想把 range in(2,3) 的变成4， 但是还是有些没被更新。
READ_UNCOMMITTED : （可读取到 为提交的数据） 没有MVCC， 大家随便读， 没毛病。
READ COMMITTED : （可读取到提交的数据） 会有不可重复读 ， 幻读；
REPEATABLE READ ： （可重复读） 会有幻读问题 。
SERIALIZABLE ： 最高隔离级别，不允许事务并发执行，而必须串行化执行，最安全，不可能出现更新丢失、脏读、不可重复读、幻读，但是效率最低。
log
redo log 在数据更改后 会记录 维护 和Double Write 维护<持久性>
undo log 要更改 那么会记录。 方便回滚 和MVCC的实现 <原子性>.
next-key-lock 好文：http://hedengcheng.com/?p=771