WAL技术(Write-Ahead Logging) 先写日志，再写磁盘:
当有一条记录需要更新的时候，InnoDB 引擎就会先把记录写到 redo log（粉板）里面，并更新内存，这个时候更新就算完成了。同时，InnoDB 引擎会在适当的时候，将这个操作记录更新到磁盘里面，而这个更新往往是在系统比较空闲的时候做。
刚刚update的语句还在缓存中未持久化磁盘，此时select是直接读取内存
redo log
InnoDB的redo log固定大小，比如可配置一组四个文件，每个文件1G,有两个指针，write pos记录当前写位置，边写边后移，checkpoint记录当前更新到文件的位置。write pos追上checkpoint，表示满了，停下来进行部分保存。有了redo log,InnoDB就可以保证即便数据库发生异常启动，之前的记录不会丢失，此能力叫 crash-safe
change buffer
当需要更新一个数据页时，如果数据页在内存中就直接更新，而如果这个数据页还没有在内存中的话，在不影响数据一致性的前提下，InnoDB 会将这些更新操作缓存在 change buffer 中，这样就不需要从磁盘中读入这个数据页了。在下次查询需要访问这个数据页的时候，将数据页读入内存，然后执行 change buffer 中与这个页有关的操作。通过这种方式就能保证这个数据逻辑的正确性。
注意:
1、唯一索引不会用到 change buffer，插入值时，会查询数据是否唯一，也就没有必要用change buffer，所以唯一索引一定意义上会影响性能(如果buffer pool上有数据)
2、适合写多读少的场景
插入一条数据的过程
插入一条数据: insert into t(id,k) values(id1,k1),(id2,k2);
假设当前 k 索引树的状态，查找到位置后，k1 所在的数据页在内存 (InnoDB buffer pool) 中，k2 所在的数据页不在内存中
分析这条更新语句，你会发现它涉及了四个部分：内存、redo log（ib_log_fileX）、 数据表空间（t.ibd）、系统表空间（ibdata1）。
这条更新语句做了如下的操作（按照图中的数字顺序）：
1、Page 1 在内存中，直接更新内存。
2、Page 2 没有在内存中，就在内存的 change buffer 区域，记录下“我要往 Page 2 插入一行”这个信息。
3、将上述两个动作记入 redo log 中（图中 3 和 4）。
做完上面这些，事务就可以完成了。所以，你会看到，执行这条更新语句的成本很低，就是写了两处内存，然后写了一处磁盘（两次操作合在一起写了一次磁盘），而且还是顺序写的。
查询一条语句的过程
