这是该系列的第三篇文章（1，2）了。之所以选择并发线程控制着手研究InnoDB的代码有两个原因：第一，这段代码相对独立，不要了解太多的相关代码就可以理解；第二，稍微多看一些代码你会发现，到处都是线程并发控制相关的代码出现，所以这也是一个基础。
在第一篇中，介绍了InnoDB内部排他锁的实现，第二篇则介绍InnoDB内部读写锁的实现原理（这里说的“内部”是为了区别于数据库层面的读写锁）。本篇则将延续第二篇，介绍读写锁相关的代码实现。 (more…)
MySQL
-
-
前面做了一个开始，沿着路慢慢走下去。
0. 起源开始之前，这里可以说说这次准备开始研究源代码的一个很大诱因了。前一段时间在生产环境遇到了一个InnoDB报错，这个错误甚至会导致InnoDB Crash：
InnoDB: Warning: a long semaphore wait:
–Thread 1222654272 has waited at ./include/btr0btr.ic line 53 for 241.00 seconds the semaphore:
S-lock on RW-latch at 0x2aaab510b818 created in file buf/buf0buf.c line 680沿着这里的线索 buf/buf0buf.c line 680 找到了：
678 mutex_create(&block->mutex, SYNC_BUF_BLOCK);
679
680 rw_lock_create(&block->lock, SYNC_LEVEL_VARYING);
681 ut_ad(rw_lock_validate(&(block->lock)));继续，就开始看rw_lock_create的实现，然后感觉需要看更多基础的一点的内容，这样就有了前面一片文章，继续研究，就有了现在的这篇文章。 (more…)
-
作为DBA关心的更多的可能是原理、机制，对于源码一般大家也不是特别关心，也不太用得上。而且对于对于源代码级别的细节也很难用文字表达自己的理解，最终理解必须还是需要自己去看看每一行代码到底是怎样的。也读过《Understanding.MySQL.Internals》的大部分章节，作者也是偏重于从代码的实现目的（原理、机制）来介绍的，国内的《MySQL核心内幕》（个人对于“核心内幕”这个词有莫名的反感）算是更多的从源码开始介绍MySQL了，可是这本书也许是授予篇幅的限制，介绍的东西也并不多。
开始写这篇文章，不能期待自己能写多少，也不能期待自己能研究多少，不过至少走出了自己探索的第一步。文章的宗旨不在于能够多么细致的分析MySQL的源代码，而是希望能给自己，能给他人打开走向源代码的第一道门。
我是BNU数学系毕业的，对C语言知道甚少，C语言的经历大概就是“计算方法”课程中实现的求解各种方程的撇脚程序了。所以虽然我会极力避免错误，但是相信还是会犯一堆错误，希望各位看官能够宽容点，有错误指出来，慢慢改正。
0. 开始InnoDB的代码通过宏定义考虑很多平台的兼容问题，这里分析的主要是类Unix/Linux平台（POSIX标准）的代码段，所以下面的很多代码段也是删除相关兼容性代码的。本文InnoDB源码是Plugin1.0.6版本。 (more…)
-
使用rpm包，或者apt-get、yum等方式安装MySQL已经很方便了，不过我还是更喜欢编译安装。编译安装的好处：平台无关、安装的MySQL目录独立（方便清楚），据说有更好的性能和平台耦合。缺点，编译安装较慢（不过现在8核CPU编译起来也很快了）。
1. MySQL编译参数
常用的参数有：
CFLAGS="-O3" CXX=gcc CXXFLAGS="-O3 -felide-constructors \ -fno-exceptions -fno-rtti" ./configure \ --prefix=/data/mysql --with-extra-charsets=latin1,gbk,utf8 \ --with-plugins=partition,heap,innobase,myisam,myisammrg,csv \ --enable-assembler make make install“If you are using a version of gcc recent enough to understand the -fno-exceptions option, it is very important that you use this option. Otherwise, you may compile a binary that crashes randomly. Also use -felide-constructors and -fno-rtti along with -fno-exceptions.” (more…)
-
当管理的MySQL主机越来越多的时候，遇到Bug的可能性也就越来越大了。基本上，每隔一段时间，我们都会遇到一个Bug或者版本兼容问题。有些Bug已经修复（Bug #44571），有些Bug无法重现或者修复（Bug #39168）。即使Bug能够重现，我们也不能期待MySQL/Innobase能够多快的给出Patch，他们没有这个义务，我们也没有权利要求。
如何处理Bug？
尝试到找Bug重现的场景，确定他是一个Bug，而不是一个Mistake。一般遇到Bug，都能在MySQL Bug找到线索，如果能够确定是Bug，可以看看新的版本是不是已经修复，如果修复则可以考虑升级小版本号。对于更高的小版本号，我们有如下假设（或者认为）
- 更高的小版本号解决了更多Bug；
- 如果更高的小版本有新特性，那么意味着新特性可能带来更多的Bug；
- 更高的小版本，仍然会有和老版本不兼容的地方；
- 更高的小版本，有很cool的新特性；
- 一般，小版本的升级不会影响应用。
所以，一般遇到Bug，新的小版本如果有修复，我们将优先考虑升级小版本号。
另外，找到Bug重现的场景，还可以考虑绕过Bug（workaround），让自己的应用或者DDL尽量避免Bug出现。有时候，新版本新特性会带来一些Bug，不得以我们还可以考虑降级版本，虽然这是不推荐的做法，因为这样的可能陷入死循环。
Bug？Debug！
纵然，Innobase/MySQL AB已经被Oracle收购，MySQL的源代码仍然受到GPL的保护，所以我们仍然能够获得源代码，这就意味着我们自己Debug也成为可能。很多做开源方案的团队、公司已经发布了很多Patch，一般是做性能提升或者功能增强，他们也在MySQL Bug上提交了很多Patch建议。
这里的另一个问题是，自己的团队是否可能去Debug、打补丁？一般地，如果能够找到源代码的Bug，将其提交到MySQL Bug上，等待更加理解整个架构的人去将代码Merge到源码树中，一般是比较靠谱的办法。这大概也是为什么，目前开源社区、团队产生的一般是性能提升或者功能增强补丁，而很少Debug补丁。