資深數(shù)據(jù)庫工程師點(diǎn)評MySQL 5.5的"罪與罰"
作者簡介
Baron Schwartz
Baron Schwartz 是一名軟件工程師，他住在弗吉尼亞州的Charlottesville，在網(wǎng)上用的名字是Xaprb，這是他名字的***部分按QWERTY鍵盤的順序打在Dvorak鍵盤上時(shí)顯示出來的名字。當(dāng)他不忙于解決有趣的編程挑戰(zhàn)時(shí)，Baron就會和他的妻子Lynn、狗Carbon一起享受閑暇時(shí)光。他的關(guān)于軟件工程的博客地址是http://www.xaprb.com/blog。其著作《High Performance MySQL》曾榮獲2009年Jolt圖書大獎(jiǎng)。
想查看本書完整中文版，請鏈接：http://book.51cto.com/art/201001/180988.htm
最近一段時(shí)間我很少在博客文章中討論MySQL的功能改變。不過近幾年以來MySQL和InnoDB工程師確實(shí)一直在進(jìn)行著大量的工作，現(xiàn)在隨著MySQL 5.5版的發(fā)布，他們的工作成果得以向人們展示，因此現(xiàn)在我們有必要對他們表示祝賀和感激，同時(shí)也有必要談?wù)勎覍υ摪姹镜目捶ā?/p>
在近日舉行MySQL大會上，我曾經(jīng)非常激動(dòng)的等待MySQL 5.5的到來，不過事實(shí)證明我對其有些高估。當(dāng)然，MySQL 5.5中值得談?wù)摰牡胤胶芏啵琁nnoDB和MySQL團(tuán)隊(duì)也發(fā)表了多篇相關(guān)博客文章。以下是我對MySQL 5.5善惡丑的個(gè)人意見。
選擇InnoDB作為默認(rèn)存儲引擎
最初看到這一點(diǎn)時(shí)，我并沒有對其太在意。資深用戶能夠以各種方式來實(shí)現(xiàn)這一點(diǎn)。但是MySQL專家摩根·托克(Morgan Tocker)表示，這實(shí)際上是一個(gè)重大改變。它將引發(fā)MySQL使用方式的巨變。過去用戶通常是最初使用MyISAM存儲引擎，然后學(xué)習(xí)轉(zhuǎn)向數(shù)據(jù)管理功能更強(qiáng)大的InnoDB;現(xiàn)在是從一開始就使用更高級和更復(fù)雜的存儲引擎。我們將看到更多的人開始學(xué)習(xí)了解InnoDB，而知道MyISAM引擎的人則會減少很多。人們討論的話題不再是“為什么我要從MyISAM轉(zhuǎn)向InnoDB?”而是“我聽說還有一個(gè)MyISAM引擎，什么情況下我應(yīng)該試用它?”
對MySQL來說，這是一個(gè)非常明智的舉動(dòng)。
InnoDB完善
這是一個(gè)復(fù)雜的話題。某些改變非常不錯(cuò)。某些改變則看上去很像是XtraDB功能的改良實(shí)現(xiàn)，當(dāng)然XtraDB同樣也是有個(gè)優(yōu)秀的存儲引擎。
在以前討論XtraDB的文章中，我提到了還原時(shí)間和獨(dú)立清理線程的改進(jìn)，以及支持多重回滾區(qū)域的改變。這些概念已經(jīng)被XtraDB用戶證明了在真實(shí)世界中的效果，我希望InnoDB進(jìn)行了大量工作來實(shí)施這些概念。InnoDB的還原功能看上去非常不錯(cuò)，盡管目前還不清楚它是否比XtraDB的相應(yīng)功能更快速。通過實(shí)現(xiàn)這些改進(jìn)，InnoDB實(shí)現(xiàn)了一個(gè)巨大的飛躍。
對于多緩沖池(multiple buffer pools)功能，我并不感到十分激動(dòng)。該功能也是無奈之舉，因?yàn)槟壳皼]有一個(gè)***方案來解決這個(gè)難題。緩沖池本身已經(jīng)非常難于管理(運(yùn)行時(shí)無法改變大小，以及不能對其索引等)”，新版MySQL數(shù)據(jù)庫在這一方面看似也并無多大改進(jìn)。至于所謂的真正提升內(nèi)在架構(gòu)，就像一個(gè)零和(zero-sum)游戲而已，僅僅只是提高了性能，我認(rèn)為這不是一個(gè)符合未來考驗(yàn)(future-proof)的狹隘式優(yōu)化。我認(rèn)為將來這種方案將會發(fā)生變化。除非緩沖池的其它問題得以解決，未來對其進(jìn)行的任何增強(qiáng)都將可能帶來諸如存儲殘片的問題。當(dāng)然，只是一味批評而未提出任何建設(shè)性意見，不會對它有任何幫助，但是我知道我的所有建議缺乏足夠的證據(jù)。
剝離互斥鎖是一件非常復(fù)雜的工作，我目前對此還沒有什么看法。基準(zhǔn)點(diǎn)不錯(cuò)，但現(xiàn)實(shí)世界往往會發(fā)生意料之外的事情。因此我們應(yīng)該看一下其真正的性能改變。我知道InnoDB在這方面做了大量工作，不過我認(rèn)為Percona無需模仿InnoDB，不過前者可以靜觀后者該功能的表現(xiàn)，然后吸取其教訓(xùn)作出更好的改進(jìn)。
同步I/O令我十分擔(dān)憂;I/O不容易控制，這是一個(gè)復(fù)雜的變動(dòng)。它是又一件令人難于甚至無法理解的事情。
我懷疑刪除緩沖功能可能已經(jīng)完全偏離軌道，它采取了與插入緩沖相同的方式。在寫緩沖的時(shí)候，對緩沖機(jī)制的控制非常簡陋。無法控制緩沖的大小，無法在后臺卸載緩沖(XtraDB可以實(shí)現(xiàn)此點(diǎn))。但是如果InnoDB解決此缺陷，也不是一件令人吃驚的事情，我認(rèn)為這不是一件難于實(shí)現(xiàn)的事情。插入緩沖的操作有時(shí)是非常奇怪的，缺乏必要的控制，這將帶來性能問題。從這一點(diǎn)上來說，即使***版的InnoDB也與XtraDB有差距。
元數(shù)據(jù)信息庫Performance Schema
元數(shù)據(jù)信息庫Performance Schema從誕生的***天起，就不曾獲得過我的好感。它屬于閉門造車的一個(gè)象牙塔項(xiàng)目，創(chuàng)建者缺乏實(shí)際工作經(jīng)驗(yàn)。對于普通用戶來說用處不大;對于MySQL和InnoDB開發(fā)者來說，它或許還有些用處，但也不是***解決方案。在那些介紹它的博客或技術(shù)文章中，都沒有列出該功能的實(shí)際案例，原因是人們無法列舉出證明它實(shí)際用途的好例子。我們只是看到一些泛泛之談，諸如“它可以把問題追溯到相關(guān)文件和源代碼行，能夠讓用戶真正了解發(fā)生在后端的秘密。”
結(jié)束語
令我感到振奮的是，MySQL團(tuán)隊(duì)不僅繼續(xù)大力進(jìn)行服務(wù)器和InnoDB方面的開發(fā)研究，而且最近數(shù)年的辛勤工作最終轉(zhuǎn)化為實(shí)際的產(chǎn)品功能。因此應(yīng)該將更多的贊譽(yù)之詞贈送給MySQL和InnoDB，并希望它們繼續(xù)這種步伐，同時(shí)廣納諫言、不斷改進(jìn)。
【編輯推薦】
