《MYSQL5.7數(shù)據(jù)庫性能怎么樣？有實測過嗎？MySQL5.7使用InnoDB每秒QPS》要點(diǎn)：
本文介紹了MYSQL5.7數(shù)據(jù)庫性能怎么樣？有實測過嗎？MySQL5.7使用InnoDB每秒QPS，希望對您有用。如果有疑問，可以聯(lián)系我們。

相關(guān)主題：MYSQL調(diào)優(yōu)

在 MySQL 5.7 中使用 InnoDB Memcached 插件實現(xiàn)每秒 100 萬 QPS

原文：http://www.oschina.net/translate/mysql-5-7-innodb-memcached-plugins

在上周， Tomas 在 MySQL Percona Live Conference in London ，宣布了MySQL 5.7的版本--在只讀的（Read-Only）測試環(huán)境，InnoDB 的 Memcached plugin的版本中，可以處理 每秒 1,000,000 次的查詢。這個文章就是證實這個說法的。

實際上，我至今也沒有準(zhǔn)確說法，到底可拓展性有多么的準(zhǔn)確和有多少的性能限制在這里面..我們可以在最新的MySQL 5.7 中可以得到最大的性能提升，并且，并且可以讓我們輕松的在“普通的”（normal）SQL 在只讀的環(huán)境中（Read-Only workload） 測試到 500K QPS 。接下來，更多的性能提升在InnoDB Memcached Plugin代碼中變?yōu)榭赡埽欢磺卸际悄敲醋匀弧Ｓ绕湓贔acebook團(tuán)隊，他們突破并展現(xiàn)出巨大的性能點(diǎn)。當(dāng)然，F(xiàn)acebook給我們提供了一個測試case，我們也用它來成功的提高了我們代碼。最終，同樣的測試案例會在下面的測試評分結(jié)果中展示出來;-）

這個測試是在”獨(dú)立“（standalone）模式上測試的。（包括服務(wù)器，客戶端都在上面運(yùn)行）。所以，我們使用我們實驗室最大的HW box - 一個48核的機(jī)器。這個服務(wù)器能夠迅速的給我們指出一個存在的，或者潛在的性能瓶頸（最有趣的是，大部分他們都是在memcached代碼上面）。然而，QPS 依賴于內(nèi)存和CPU。因此，這臺服務(wù)器是只有2Ghz的CPU 核，如果有存在其他更快的HW，你可能能得到更好的積分統(tǒng)計 ：-）

現(xiàn)在，比較 最好-最好 的QPS結(jié)果如下：

我曾經(jīng)把MySQL5.6放上神壇，給它打上“有史以來最好的結(jié)果”這樣的標(biāo)簽;-))——由于一部分的Memcached代碼性能提高也會反過來提升MySQL5.6的性能，所以我們也期望在5.6的下一版本中也能運(yùn)行的良好。實際上，只需要MySQL5.7，你就可以達(dá)到一個很高的水平……

在我在倫敦的Percona現(xiàn)場討論會上，我曾經(jīng)展示過下面這些圖表——Memcached QPS是符合InnoDB的“dml_read/sec”的狀態(tài):

這些圖表代表著在“上一版”MySQL上所做的4個Memcached負(fù)載測試：

• #1運(yùn)行在48核的機(jī)器上……——我們遇到了與MVCC相關(guān)的服務(wù)器沖突（在最新版的MySQL5.7中已經(jīng)修復(fù)了）

• #2限制MySQL服務(wù)運(yùn)行在16核的機(jī)器上，以降低這個沖突……——然后，我們遇到了事務(wù)沖突（這也在最新版的MySQL5.7中修復(fù)了）

• #3調(diào)整Memcached plugin，在一個獨(dú)立的事務(wù)內(nèi)部保持一些讀操作——神啊，救救我吧，我又遇到了一些其他的沖突……

• #4限制MySQL服務(wù)運(yùn)行在8核的機(jī)器上，看是否會降低沖突——事實表明，最大QPS有所提高（在32個用戶的情況下），但是整體性能卻更糟了……

相反的，在最新版的MySQL5.7中，情況確實完全不同：

這些圖所表示的是兩個測試：

• #1-運(yùn)行在48核的機(jī)器上（不做太多評論;-)）

• #2-調(diào)整了一些參數(shù)，在一個獨(dú)立的內(nèi)部事務(wù)中保持一些讀取的操作，結(jié)果只有在QPS的峰值上稍微好點(diǎn)，其他方面沒有什么區(qū)別。

接下來為了更好的感受到QPS的差距，我們將這些測試結(jié)果放在一個圖表中：

你可以更形象的看到這兩者的不同。

• 圖表的左半部分曲線代表的QPS水平都是在“舊版”的MySQL5.6/5.7上得到的。

• 然后右半部分的曲線是在最新版的MySQL5.7上得到的。

這項工作仍在進(jìn)展中，關(guān)于在這個最新的MySQL 5.7版本中我們實現(xiàn)的巨大進(jìn)步，我會讓Sunny 和 Jimmy給你們提供其中所有深入的細(xì)節(jié)。

我不知道這里的性能極限在于哪里。可能只存在于HW（HardWare）層面。我也不知道是否有足夠龐大的HW來觀察它;-)——現(xiàn)在經(jīng)由一個單獨(dú)的1Gbit網(wǎng)絡(luò)鏈接，我們已經(jīng)觀察到超過700K QPS的性能了，當(dāng)這個來自于單獨(dú)網(wǎng)絡(luò)鏈路的極限峰值到達(dá)時，主要的麻煩卻來自于客戶端處理程序，而不是服務(wù)器——所以，看上去相比較“原始的”Memcached本身來說，Memcached @InnoDB具有更好的伸縮性;-)——那么，當(dāng)有幾個網(wǎng)絡(luò)鏈接啟用（或者僅僅只是使用更快速的網(wǎng)卡）的時候可能會有什么樣的性能呢——還有許多東西需要去探索發(fā)掘的！而且RW（ReadWrite）工作負(fù)載性能也是另一項挑戰(zhàn);-)

感謝Sunny和Jimmy！還要特殊感謝yoshinori（Facebook）！-我認(rèn)為這是一個很典型的例子！ 

想要了解更多關(guān)于Memecached Plugin 的設(shè)計-你可以follow this link : https://blogs.oracle.com/MySQL/entry/nosql_memcached_api_for_mysql 。-然后，你把結(jié)果都印在心里面，我現(xiàn)在讓你現(xiàn)在想象一下”如果是數(shù)據(jù)是直接通過“本地”（native）InnoDB API 訪問的，然后通過Memcached 層面?zhèn)鬏數(shù)摹埃闼诖悄姆N性能？ 

Rgds, 
-Dimitri 

轉(zhuǎn)載請注明本頁網(wǎng)址：
http://www.fzlkiss.com/jiaocheng/130.html