<b>资深数据库工程师点评MySQL 5.5的"罪与罚"</b>[MySQL防范]
本文“<b>资深数据库工程师点评MySQL 5.5的"罪与罚"</b>[MySQL防范]”是由七道奇为您精心收集,来源于网络转载,文章版权归文章作者所有,本站不对其观点以及内容做任何评价,请读者自行判断,以下是其具体内容:
作者简介
Baron Schwartz
Baron Schwartz 是一名软件工程师,他住在弗吉尼亚州的Charlottesville,在网上用的名字是Xaprb,这是他名字的第一部份按QWERTY键盘的次序打在Dvorak键盘上时显示出来的名字.当他不忙于办理风趣的编程挑衅时,Baron就会和他的老婆Lynn、狗Carbon一同享用闲暇光阴.他的关于软件工程的博客地址是http://www.xaprb.com/blog.其著作《High Performance MySQL》曾荣获2009年Jolt图书大奖.
想查看本书完好中文版,请链接:http://book.bitscn.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,并但愿它们持续这种步伐,同时广纳谏言、不断改良.
以上是“<b>资深数据库工程师点评MySQL 5.5的"罪与罚"</b>[MySQL防范]”的内容,如果你对以上该文章内容感兴趣,你可以看看七道奇为您推荐以下文章:
本文地址: | 与您的QQ/BBS好友分享! |