InnoDB储存引擎的架构设计
InnoDB的重要内存结构：缓冲池
引擎要执行更新语句的时候 ，比如对“id=10”这一行数据，他其实会先将“id=10”这一行数据看看是否在缓冲池里，如果不在的 话，那么会直接从磁盘里加载到缓冲池里来，而且接着还会对这行记录加独占锁
undo日志文件：如何让你更新的数据可以回滚？
假设“id=10”这行数据的name原来是“zhangsan”，现在我们要更新为“xxx”，那么此时我们得先 把要更新的原来的值“zhangsan”和“id=10”这些信息，写入到undo日志文件中去
更新buffer pool中的缓存数据
当我们把要更新的那行记录从磁盘文件加载到缓冲池，同时对他加锁之后，而且还把更新前的旧值写入undo日志文件 之后，我们就可以正式开始更新这行记录了，更新的时候，先是会更新缓冲池中的记录，此时这个数据就是脏数据。因为这个时候磁盘上“id=10”这行数据的name字段还是“zhangsan”，但是内存里这行数据已经被修改了，所以就会叫他是脏数据。
Redo Log Buffer：万一系统宕机，如何避免数据丢失？
把对内存所做的修改写入到一个Redo Log Buffer里去，这也是内存里的一个缓冲区，是用来存放redo日志的
提交事务的时候将redo日志写入磁盘中
我们想要提交一个事务了，此时就会根据一定的策略把redo日志从redo log buffer里刷入到磁盘文件里去，此时这个策略是通过innodb_flush_log_at_trx_commit来配置
- 当这个参数的值为0的时候，那么你提交事务的时候，不会把redo log buffer里的数据刷入磁盘文件的，此时可能你都 提交事务了，结果mysql宕机了，然后此时内存里的数据全部丢失
- 当这个参数的值为1的时候，你提交事务的时候，就必须把redo log从内存刷入到磁盘文件里去，只要事务提交成功，那么redo log就必然在磁盘里了，就算mysql宕机，当mysql重启之后，他可以根据redo日志去恢复之前做过的修改
- 当这个参数的值为2的时候，提交事务的时候，把redo日志写入磁盘文件对应的os cache缓存里去，而不是直接进入磁盘文件，可 能1秒后才会把os cache里的数据写入到磁盘文件里去，万一此时你要 是机器宕机了，那么os cache里的redo log就会丢失，同样会让你感觉提交事务了，结果数据丢了
