为什么要有redo log

        接之前对于binlog的介绍，binlog是一种逻辑日志，可以实现数据库数据在之前任意时刻的回滚，也可进行主从复制，但是binlog有一个致命的缺点，就是记录的不够细致，怎么理解细致这个词呢?就是说，虽然binlog里面会针对于一个事务里的sql进行完整的记录也会记录事务的开启提交状态，但是呢这都是逻辑层面的，比如说记录一条sql (statement格式)，比如说记录xx行数据+1，xx行数据-1（row格式)，但是我们思考一个问题，mysql真实的数据存储是通过数据页的形式记录在磁盘的，也就是说，一个事务涉及到很多sql，一条sql语句可能涉及到很多数据页的变更，只通过binlog我们是无法判断一个事务的修改到底有没有真正落实到磁盘上的，为什么呢?其实很简单，比如说我们考试打小抄都只抄了思路没抄答案，你说你考试的时候能知道自己回答的一定是正确的吗?一定是和正确答案一字不落的吗?
所以我们之前说的binlog可以进行数据回滚的场景，都是在数据库正常运行的情况下，没有问题，如果说在事务执行的过程中突然机器宕机，这种情况binlog就有点尴尬了，光凭逻辑日志，搞不定。
        所以我们就有了更牛逼的解决方案，各位小天才们都能想到了，既然binlog的问题在于数据库突然宕机的时候我们无法判断sql语句的修改到底有没有真正落到磁盘上，那么我们直接搞一个新的日志专门去记录针对磁盘数据页的修改不就行了吗?
        想到这里，各位绝对都是数一数二的人才了，都能够独立开发数据库的日志体系，没错哈，说了这么一大堆，这就是redolog的由来,redolog又被称作物理日志，因为他专门记录磁盘数据页的修改，redolog被设计出来的初衷其实就是为了解决几个问题，1宕机恢复⒉事务的一致性