资深数据库工程师点评MySQL 5.5的

　　作者简介

Baron Schwartz

　　Baron Schwartz 是一名软件工程师，他住在弗吉尼亚州的Charlottesville，在网上用的名字是Xaprb，这是他名字的第一部分按QWERTY键盘的顺序打在Dvorak键盘上时显示出来的名字  。当他不忙于解决有趣的编程挑战时，Baron就会和他的妻子Lynn、狗Carbon一起享受闲暇时光  。他的关于软件工程的博客地址是http://www.xaprb.com/blog  。其著作《High Performance MySQL》曾荣获2009年Jolt图书大奖  。

想查看本书完整中文版，请链接：http://book.51cto.com/art/201001/180988.htm

　　最近一段时间我很少在博客文章中讨论MySQL的功能改变  。不过近几年以来MySQL和InnoDB工程师确实一直在进行着大量的工作，现在随着MySQL 5.5版的发布，他们的工作成果得以向人们展示，因此现在我们有必要对他们表示祝贺和感激，同时也有必要谈谈我对该版本的看法  。

　　在近日举行MySQL大会上，我曾经非常激动的等待MySQL 5.5的到来，不过事实证明我对其有些高估  。当然，MySQL 5.5中值得谈论的地方很多，InnoDB和MySQL团队也发表了多篇相关博客文章  。以下是我对MySQL 5.5善恶丑的个人意见  。

　　选择InnoDB作为默认存储引擎

　　最初看到这一点时，我并没有对其太在意  。资深用户能够以各种方式来实现这一点  。但是MySQL专家摩根·托克(Morgan Tocker)表示，这实际上是一个重大改变  。它将引发MySQL使用方式的巨变  。过去用户通常是最初使用MyISAM存储引擎，然后学习转向数据管理功能更强大的InnoDB;现在是从一开始就使用更高级和更复杂的存储引擎  。我们将看到更多的人开始学习了解InnoDB，而知道MyISAM引擎的人则会减少很多  。人们讨论的话题不再是“为什么我要从MyISAM转向InnoDB?”而是“我听说还有一个MyISAM引擎，什么情况下我应该试用它?”

　　对MySQL来说，这是一个非常明智的举动  。

　　InnoDB完善

　　这是一个复杂的话题  。某些改变非常不错  。某些改变则看上去很像是XtraDB功能的改良实现，当然XtraDB同样也是有个优秀的存储引擎  。

　　在以前讨论XtraDB的文章中，我提到了还原时间和独立清理线程的改进，以及支持多重回滚区域的改变  。这些概念已经被XtraDB用户证明了在真实世界中的效果，我希望InnoDB进行了大量工作来实施这些概念  。InnoDB的还原功能看上去非常不错，尽管目前还不清楚它是否比XtraDB的相应功能更快速  。通过实现这些改进，InnoDB实现了一个巨大的飞跃  。

　　对于多缓冲池(multiple buffer pools)功能，我并不感到十分激动  。该功能也是无奈之举，因为目前没有一个最佳方案来解决这个难题  。缓冲池本身已经非常难于管理(运行时无法改变大小，以及不能对其索引等)”，新版MySQL数据库在这一方面看似也并无多大改进  。至于所谓的真正提升内在架构，就像一个零和(zero-sum)游戏而已，仅仅只是提高了性能，我认为这不是一个符合未来考验(future-proof)的狭隘式优化  。我认为将来这种方案将会发生变化  。除非缓冲池的其它问题得以解决，未来对其进行的任何增强都将可能带来诸如存储残片的问题  。当然，只是一味批评而未提出任何建设性意见，不会对它有任何帮助，但是我知道我的所有建议缺乏足够的证据  。

　　剥离互斥锁是一件非常复杂的工作，我目前对此还没有什么看法  。基准点不错，但现实世界往往会发生意料之外的事情  。因此我们应该看一下其真正的性能改变  。我知道InnoDB在这方面做了大量工作，不过我认为Percona无需模仿InnoDB，不过前者可以静观后者该功能的表现，然后吸取其教训作出更好的改进  。

　　同步I/O令我十分担忧;I/O不容易控制，这是一个复杂的变动  。它是又一件令人难于甚至无法理解的事情  。

　　我怀疑删除缓冲功能可能已经完全偏离轨道，它采取了与插入缓冲相同的方式  。在写缓冲的时候，对缓冲机制的控制非常简陋  。无法控制缓冲的大小，无法在后台卸载缓冲(XtraDB可以实现此点)  。但是如果InnoDB解决此缺陷，也不是一件令人吃惊的事情，我认为这不是一件难于实现的事情  。插入缓冲的操作有时是非常奇怪的，缺乏必要的控制，这将带来性能问题  。从这一点上来说，即使最新版的InnoDB也与XtraDB有差距  。

　　元数据信息库Performance Schema

　　元数据信息库Performance Schema从诞生的第一天起，就不曾获得过我的好感  。它属于闭门造车的一个象牙塔项目，创建者缺乏实际工作经验  。对于普通用户来说用处不大;对于MySQL和InnoDB开发者来说，它或许还有些用处，但也不是最佳解决方案  。在那些介绍它的博客或技术文章中，都没有列出该功能的实际案例，原因是人们无法列举出证明它实际用途的好例子  。我们只是看到一些泛泛之谈，诸如“它可以把问题追溯到相关文件和源代码行，能够让用户真正了解发生在后端的秘密  。”

　　结束语

　　令我感到振奋的是，MySQL团队不仅继续大力进行服务器和InnoDB方面的开发研究，而且最近数年的辛勤工作最终转化为实际的产品功能  。因此应该将更多的赞誉之词赠送给MySQL和InnoDB，并希望它们继续这种步伐，同时广纳谏言、不断改进  。