从一条更新SQL的执行过程窥探InnoDB之REDOLOG( 二 )

那么我们需要什么样的REDO呢？
首先， REDO的维护增加了一份写盘数据，同时为了保证数据正确，事务只有在他的REDO全部落盘才能返回用户成功， REDO的写盘时间会直接影响系统吞吐，显而易见， REDO的数据量要尽量少。其次，系统崩溃总是发生在始料未及的时候，当重启重放REDO时，系统并不知道哪些REDO对应的Page已经落盘，因此REDO的重放必须可重入，即REDO操作要保证幂等。最后，为了便于通过并发重放的方式加快重启恢复速度， REDO应该是基于Page的，即一个REDO只涉及一个Page的修改。
数据量小是LogicalLogging的优点，而幂等以及基于Page正是PhysicalLogging的优点。 InnoDB采取了一种称为PhysiologicalLogging的方式，来兼得二者的优势。所谓PhysiologicalLogging ，就是以Page为单位，但在Page内以逻辑的方式记录。举个例子，一种作用于Page类型的REDOLOG中记录了对Page中一个Record的修改，方法如下：（PageID ， RecordOffset ， (Filed1,Value1)…(Filedi,Valuei)…)
【从一条更新SQL的执行过程窥探InnoDB之REDOLOG】其中， PageID指定要操作的Page页， RecordOffset记录了Record在Page内的偏移位置，后面的Field数组，记录了需要修改的Field以及修改后的Value 。
2.4REDOLOG的记录内容

文章图片
其中Type就是记录的作用对象(根据REDO记录不同的作用对象，可划分为三个大类：作用于Page ，作用于Space以及提供额外信息的Logic类型) ， SpaceID和PageNumber唯一标识一个Page页，这三项是所有REDO记录都需要有的头信息。
后面的是MLOG_REC_UPDATE_IN_PLACE类型(作用于Page)独有的，其中RecordOffset用给出要修改的记录在Page中的位置偏移， UpdateFieldCount说明记录里有几个Field要修改，紧接着对每个Field给出了Field编号(FieldNumber) ，数据长度（FieldDataLength）以及数据（FiledData）
3总结
通过对一个更新SQl语句执行过程的跟踪，了解熟悉Mysql的执行过程，了解REDOLOG的数据的内容格式，从根本上理解REDOLOG的设计的思路和原理，为以后的应用系统的开发和设计提供思想上的借鉴和实践。
作者：王义杰返回搜狐，查看更多
责任编辑：