选择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，并希望它们继续这种步伐，同时广纳谏言、不断改进。