zerok的专栏

在上一篇《innodb源码分析之重做日志结构》中我们知道redo log的基本结构和日志写入步骤，那么redo log是怎么进行数据恢复的呢？在什么时候进行redo log的日志推演呢？redo log的推演只有在数据库异常或者关闭后，数据库重新启动时会进行日志推演，将数据库状态恢复到关闭前的状态。那么这个过程是怎么进行的呢？以下我们逐步来解析。1.recv_sys_t结构 innod

在innodb的引擎实现中，为了实现事务的持久性，构建了重做日志系统。重做日志由两部分组成：内存日志缓冲区(redo log buffer)和重做日志文件。这样设计的目的显而易见，日志缓冲区是为了加快写日志的速度，而重做日志文件为日志数据提供持久化的作用。在innodb的重做日志系统中，为了更好实现日志的易恢复性、安全性和持久化性，引入了以下几个概念：LSN、log block、日志文件组、che

在表空间结构分析当中，我们知道innodb的最小物理存储分配单位是page页，在MySQL-3.23版本的源码中，页只有两种页，一种是index page，一种是undo page。其类型值定义在fil0fil.h当中。                FIL_PAGE_INDEX                         数据索引页，在表空间的inode page和xdes page都是

innodb在实现表空间（table space）基于文件IO之上构建的一层逻辑存储空间管理，table space采用逻辑分层的结构：space、segment inode、extent和page.在实现层的逻辑使用了磁盘链表这种结构来管理逻辑关系。我们先来介绍磁盘链表。1.磁盘链表磁盘链表的实现fut0lst.*文件当中， innodb为了管理表空间和索引模块，定义了一个基于磁盘的链表

近一年来一直在分析关于数据库相关的源码，前段时间分析了levelDB的实现和BeansDB的实现，这两个数据库网络上分析的文章很多，也都比较分析的比较深，所以也就没有太多必要重复劳动。最近开始关注关系数据库和MYSQL，当然主要还是数据库存储引擎，首先我还是从innodb这个最流行的开源关系数据库引擎着手来逐步分析和理解。我一般分析源码的时候都是从基础的数据结构和算法逐步往上分析，遇到不明白的地方

在innodb中实现了自己的内存池系统和内存堆分配系统，在innodb的内存管理系统中，大致分为三个部分：基础的内存块分配管理、内存伙伴分配器和内存堆分配器。innodb定义和实现内存池的主要目的是提供内存的使用率和效率，防止内存碎片和内存分配跟踪和调试。我们先来看看他们的关系和结构。以下是它的关系结构图：上图中的：ut_mem_block块是基础内存管理Buddy all

innodb是一个多线程并发的存储引擎，内部的读写都是用多线程来实现的，所以innodb内部实现了一个比较高效的并发同步机制。innodb并没有直接使用系统提供的锁(latch)同步结构，而是对其进行自己的封装和实现优化，但是也兼容系统的锁。我们先看一段innodb内部的注释（MySQL-3.23）:Semaphore operations in operating systems are s

innodb作为数据库引擎，自然少不了对文件的操作，在innodb中所有需要持久化的信息都需要文件操作，例如：表文件、重做日志文件、事务日志文件、备份归档文件等。innodb对文件IO操作可以是煞费苦心，其主要包括两方面，一个是对异步io的实现，一个是对文件操作管理和io调度的实现。在MySQL-5.6版本的innodb还加入了DIRECT IO实现。做了这么多无非是优化io操作的性能。在inno

日志是innodb一个非常重要的模块，在innodb中有两类日志：redo log和undo log。其中redo log日志是用来做数据异常恢复和数据库重启时页数据同步恢复的，redo log是建立在在mini transaction基础上。数据库在执行事务时，通过mini transaction产生