Redo Log的逻辑与物理结构

日志物理结构和逻辑结构的不同

从逻辑上来讲，日志就是一个无限延长的字节流，从数据库安装好并启动的时间点开始，日志便源源不断地追加，永无结束。

但从物理上来讲，日志不可能是一个永不结束的字节流，日志的物理结构和逻辑结构，有两个非常显著的差异点：
（1）磁盘的读取和写入都不是按一个个字节来处理的，磁盘是“块”设备，为了保证磁盘的I/O效率，都是整块地读取和写入。对于Redo Log来说，就是RedoLog Block，每个Redo Log Block是512字节。为什么是512字节呢？因为早期的磁盘，一个扇区（最细粒度的磁盘存储单位）就是存储512字节数据。
（2）日志文件不可能无限制膨胀，过了一定时期，之前的历史日志就不需要了，通俗地讲叫“归档”，专业术语是Checkpoint。所以Redo Log其实是一个固定大小的文件，循环使用，写到尾部之后，回到头部覆写（实际Redo Log是一组文件，但这里就当成一个大文件，不影响对原理的理解）。之所以能覆写，因为一旦Page 数据刷到磁盘上，日志数据就没有存在的必要了。

图6-8展示了Redo Log逻辑与物理结构的差异，LSN（Log Sequence Number）是逻辑上日志按照时间顺序从小到大的编号。在InnoDB中，LSN是一个64位的整数，取的是从数据库安装启动开始，到当前所写入的总的日志字节数。实际上LSN没有从0开始，而是从8192开始，这个是InnoDB源代码里面的一个常量LOG_START_LSN。因为事务有大有小，每个事务产生的日志数据量是不一样的，所以日志是变长记录，因此LSN是单调递增的，但肯定不是呈单调连续递增。

物理上面，一个固定的文件大小，每 512 个字节一个 Block，循环使用。显然，很容易通过LSN换算出所属的Block。反过来，给定Redo Log，也很容易算出第一条日志在什么位置。假设在Redo Log中，从头到尾所记录的LSN依次如下所示：(200,289,378,478,30,46,58,69,129)
很显然，第1条日志是30，最后1条日志是478，30以前的已经被覆盖。

什么是Physiological Logging?

知道了Redo Log的整体结构，下面进一步来看每个Log Block里面Log的存储格式。这个问题很关键，是数据库事务实现的一个核心点。

1）记法1。类似Binlog的statement格式，记原始的SQL语句，insert/delete/update。

（2）记法2。类似Binlog的RAW格式，记录每张表的每条记录的修改前的值、修改后的值，类似（表，行，修改前的值，修改后的值）。

（3）记法3。记录修改的每个Page的字节数据。由于每个Page有16KB，记录这16KB里哪些部分被修改了。一个Page如果被修改了多个地方，就会有多条物理日志，如下所示：

（Page ID，offset1，len1，改之前的值，改之后的值）
 （Page ID，offset2，len2，改之前的值，改之后的值）

前两种记法都是逻辑记法；第三种是物理记法。

Redo Log采用了哪种记法呢？它采用了逻辑和物理的综合体，就是先以Page为单位记录日志，每个Page里面再采取逻辑记法（记录Page里面的哪一行被修改了）。这种记法有个专业术语，叫Physiological Logging。要搞清楚为什么要采用Physiological Logging，就得知道逻辑日志和物理日志的对应关系：

（1）一条逻辑日志可能产生多个Page的物理日志。比如往某个表中插入一条记录，逻辑上是一条日志，但物理上可能会操作两个以上的Page？为什么呢，因为一个表可能有多个索引，每个索引都是一颗B+树，插入一条记录，同时更新多个索引，自然可能修改多个Page。如果Redo Log采用逻辑日志的记法，一条记录牵涉的多个Page写到一半系统宕机了，要恢复的时候很难知道到底哪个Page写成功了，哪个失败了。

（2）即使1条逻辑日志只对应一个Page，也可能要修改这个Page的多个地方。因为一个Page里面的记录是用链表串联的，所以如果在中间插入一条记录，不仅要插入数据，还要修改记录前后的链表指针。对应到Page就是多个位置要修改，会产生多条物理日志。

所以纯粹的逻辑日志宕机后不好恢复；物理日志又太大，一条逻辑日志就可能对应多条物理日志。Physiological Logging综合了两种记法的优点，先以Page为单位记录日志，在每个Page里面再采用逻辑记法

总结

• 日志的物理结构和逻辑结构是不一样的
• Redo log 先以Page为单位记录日志，每个Page里面再采取逻辑记法(为什么?)