知识储备：
1、mysql 的crasy recovery 是通过redo log 和undo log 来完成的；
2、redo log 和undo log的记录的是对页面的物理操作；如在1024号page偏移为100的位置写入‘hello world‘；也就是说redo log 和nudo log 是否可以正确
的完成是依赖于page 的；如果这个page本身不对的话redo log 和undo log 将无法进行！
3、为什么说是无法进行而不是mysql 根据redo log ,undo log 在page 个做出一个错误的结果？这个是因为每个都有一个lsn号，这个lsn号表示的是最后一个操作这个
页面内容的事务id 、这个lsn 如果和redo log ,unod log 中的对应不上那么就不修复。
innodb_double_write:
既然redo log 和nudo log 已经有了，为了保证结果的正确性，我们只要保证page的正确性就行了；把内存中的page 刷新到table space 这个操作不可能是原子的，
也就是说有可能这个page 16 k事实上只写了3,4 k那么我们怎么能在不确定的环境中得到一个确定的结果呢？这个就是innodb_double_write的关键所在了、
innodb在刷新内存时分两步走
第一步：把page 刷新到system table space 中。
第二步：在第一步已经成功完成的基础上，把第一步刷新的页面刷新到page 真正所在的table space 当中去。
完成了以上两步后的积极意义：可以成功的排除page的内容只部分写入对redo log unod log 在做crash recovery 的影响；对page 的也入也就两种情况吧
1、部分写入，这种情况下innodb 还是可以从system table space 中找到一个正确的page 来完成crash recovery。
2、如果page 写入完成了，那么innodb 就直接可以用这个page 了，这样crash recovery 也能正确完成。
思考：
如同double write 这个名字一样，写入数据的量从之前的1份变成了2份；这样是不意味着mysql的性能下降了50%呢？
对innodb_double_write 的优化：
mysql 对innodb_double_write 也是走了先写memory，顺序写，随机写的老路子。
1、先写memory:mysql 内存中专门开了2MB用于innodb_double_write的空间叫double_write_buffer 所有要刷新的innodb_buffer_pool
中的page 先写入这个buffer。
2、每次从double_write_buffer 中刷新1M到system table space 中。
1，2这两步与第3步的开销相比要小的多，所以开户innodb_double_write 的情况下mysql 的并没有下降50%这么恐怖！