最近一段時間我很少在博客文章中討論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有差距。
