前面做了一个开始，沿着路慢慢走下去。

开始之前，这里可以说说这次准备开始研究源代码的一个很大诱因了。前一段时间在生产环境遇到了一个InnoDB报错，这个错误甚至会导致InnoDB Crash：

沿着这里的线索 buf/buf0buf.c line 680 找到了：

继续，就开始看rw_lock_create的实现，然后感觉需要看更多基础的一点的内容，这样就有了前面一片文章，继续研究，就有了现在的这篇文章。 全文阅读 »

作为DBA关心的更多的可能是原理、机制，对于源码一般大家也不是特别关心，也不太用得上。而且对于对于源代码级别的细节也很难用文字表达自己的理解，最终理解必须还是需要自己去看看每一行代码到底是怎样的。也读过《Understanding.MySQL.Internals》的大部分章节，作者也是偏重于从代码的实现目的（原理、机制）来介绍的，国内的《MySQL核心内幕》（个人对于“核心内幕”这个词有莫名的反感）算是更多的从源码开始介绍MySQL了，可是这本书也许是授予篇幅的限制，介绍的东西也并不多。

开始写这篇文章，不能期待自己能写多少，也不能期待自己能研究多少，不过至少走出了自己探索的第一步。文章的宗旨不在于能够多么细致的分析MySQL的源代码，而是希望能给自己，能给他人打开走向源代码的第一道门。

我是BNU数学系毕业的，对C语言知道甚少，C语言的经历大概就是“计算方法”课程中实现的求解各种方程的撇脚程序了。所以虽然我会极力避免错误，但是相信还是会犯一堆错误，希望各位看官能够宽容点，有错误指出来，慢慢改正。

InnoDB的代码通过宏定义考虑很多平台的兼容问题，这里分析的主要是类Unix/Linux平台（POSIX标准）的代码段，所以下面的很多代码段也是删除相关兼容性代码的。本文InnoDB源码是Plugin1.0.6版本。 全文阅读 »

很难说Optimize Table到底能不能提高系统运行效率，但是有一点是肯定的：它能够帮我们回收更多的空间、减少“碎片”（defragment）。

1. 回收空间 Defragment

在InnoDB的维护过程中，我们总会遇到磁盘耗尽、或者InnoDB Tablespaces用完的情况。这时候，在考虑扩容等方案之前，最好先使用Optimize Table试试。如果你的表大字段（Text Blob Varchar），并且更新、删除较频繁的话，Optimize之后可能会腾出大量的空间。 全文阅读 »

迫于开源社区、团体（Google Facebook Percona Xaprb等）的巨大压力，InnoDB Plugin相比Built-in版本有了很大的提升，这些提升多数来自开源社区贡献的代码，虽然本身也有一些改进。

1. 关于Fast locking

在多个线程并发访问相同资源的时候，需要使用一些InnoDB实现的互斥量（mutex）和读写锁（read/write lock）。在Unix-like平台上，InnoDB是通过Pthread的互斥量（这是POSIX标准的一部分）来实现的。在现代OS和硬件平台中，一般都有了更有效的替代方案，多数情况下这些替代方案使用更少的CPU指令和时钟周期来完成这些互斥处理。
全文阅读 »

Plugin的一个重要的特性就是增加了压缩存储。对于数据中有很多Long column(包括TEXT BLOB或者大VARCHAR)的场景能够大幅节约空间，并提升效率。

1. 谁需要压缩？

在InnoDB中，是以16K的页（Page）为基本的存储单位的。我们知道，InnoDB是的数据是在Clustered index中存储的，在Secondary index中仅存储对应数据的PK。Clustered index和Secondary index都是B-Tree结构的，所以对InnoDB数据页和索引页的压缩很大程度上就是对B-Tree节点页的压缩。

在InnoDB中，除了B-Tree节点页，还有一类数据页（Page），称为“overflow page”。当需要存储Long column时，如果当前页能够完全存储全部字段时，则存储在当前页中；如果当前页不足以存储全部，则InnoDB选择最长的字段，将其存储到一个单独的页中，我们称这样的页为“overflow page”，而原数据页仅仅需存储一个20Bytes的指针。参考下图：

所以InnoDB除了有上面的B-Tree页外，InnoDB还存储overflow页。事实上，需要压缩的数据页也就是这两类，InnoDB为了获得更好的效率，针对这两类数据页的压缩是使用不同的策略的。

全文阅读 »

本文将介绍InnoDB Plugin数据表格式的基本概念。

1. 配置参数innodb_file_format

这是一个很容易混淆的概念。目前，在InnoDB Plugin（1.0.6）配置文件中innodb_file_format支持两种：Antelope/ˈæntɪləʊp/、Barracuda/ˌbærəˈkjuːdə/。他们分别是两种文件格式的代号，在未来版本中，InnoDB将继续延续这种代号机制，它们会是Antelope, Barracuda, Cheetah, Dragon, Elk, Fox等等。

全文阅读 »