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