"MySQL性能优化" - InfoQ & Baidu技术沙龙小记

上周六去参加了一次InfoQ举办的百度技术沙龙。主题是关于MySQL的。当天到场了不少人，有些出乎我意料之外，也许是因为免费的吧：）

一共有两个演讲嘉宾，第一个来自百度，主要介绍了百度在SSD/Flash上做的工作，第二个来自terradata，主题是关于spatial database的。坦率的说，第一个演讲非常的棒，看得出来百度在SSD方面做了很多的工作，讲述得也很详细。第二个则有些像白开水，平淡无味，而且东西比较浅。

重点写一下第一个讲座的心得。

 

其实思想很简单，既然是想在SSD上做文章，自然就是想利用SSD特有的性能优势。SSD有什么好处呢，演讲嘉宾举了好些数据，简单的说，SSD对于随机读支持得很好，随机写性能一般，追加写（append write）性能不错。所以用SSD，要么应用场景切合SSD的优势，要么，从架构上改变应用场景的IO模式，使其适合SSD的特点。

对于Mysql，对于数据库来说，肯定是有大量的读操作，这点用SSD当然会有很大的性能提高，但另一方面，很多时候也会面临大量的写操作，尤其是随机写，这种情况就不是很适用于SSD了。所以，百度对Mysql的存储引擎Innodb写了一个3000行的patch。这个patch干什么用呢，说白了就一句话，将随机写转变为追加写。

那么，这事怎么做呢？

由于当时的PPT还没有放出来，所以我只是根据自己的记忆画了个草图，当然架构中的很多部分我都忽略掉了。凑合着看吧。

当mysql需要对数据库的数据进行写操作时，它并不是直接写原来的data file，而是把写好的page放在内存中，当内存中攒满了几个page后，它就将这些page组织成一个block，将这个block以append write的方式写入到另一个cache file中。这一步很重要，因为它将本来是随机写入原始data file中的操作编程了对cache file的追加写。

再看读数据，内存中会维护一份page mapping，这样当database需要读某个page的数据的时候，它会写在page mapping中查找这个page是在data file还是在cache file中，然后再从相应的file中将数据取出来。虽然cache file中的数据是非常凌乱的组织，但由于SSD的随机读性能很好，所以这一点就不成问题。

最后，cache file在某个时刻要合并到原始的data file中。这一步其实会产生大量的随机写。但是，系统可以通过调度和控制，找到一个系统负荷很小的时刻来执行这个merge操作，比如深夜。这样，就避免了大量的随机写对系统的性能造成影响。

换个角度看，其实它并不是真正的将随机写变成了追加写，而是暂时将随机写变成了追加写，然后找到一个合适的时机将这些追加写再变回为随机写。看起来似乎设计得也挺简单的。但我相信，这个方案肯定也是经过了很多次的实验和讨论才能成型的。

 

另外，SSD另一个遭人诟病的地方是它的故障率。百度给出的一个指标是每周千分之二的故障，可以说这已经是很高了。会后我私下问是怎么解决这个问题的。答案大体分为几层，首先，在设备层面，SSD本身会有一些容错恢复机制，其次，可以采用raid方式进行容错，最后，在分布式架构上设计容错算法。

 

-- END --