回顧 MySQL / InnoDB 的改善歷史。你能很容易發現。在MySQL 5.6穩定版本中從來沒有在read-only 這么快的提速，它很容易搞懂，以及在read-only（RO）有著良好的擴張性。也很期待它在read+write（RW）上達到一個較高水平。（特別是在讀取數據是數據庫主要工作的時候）

然而。我們對于RO在 MySQL 5.6的表現也十分的高興,在5.7這個版本中，主要工作集中在 read+write (RW)上, 因為在大數據的處理上還沒能達到我們的期望。但是RW依賴RO下。能夠再次提高速度。 InnoDB 團隊通過不斷的改進，強烈的推進優化著5.7這個版本的每秒的性能。

下面就按順序為大家講解

事實上，在MySQL中只讀工作量控制內部鏈接的方式有以下兩種：

任何很快的單表范圍測試的工作量主要由于MDL鏈接導致鎖住。而多表將會由于InnoDB內部構件限制(不同的表將由不同的MDL鎖保護，所以這種情況下MDL中的鏈接瓶頸將會降低)。但是同樣，也要看工作量的大小--一個比一般多的只讀工作測量將會在MySQL5.6中表現的會更好(如Sysbench OLTP_RO),同時在工作量少而快的查詢(如Sysbench Point-Selects(用外鍵去取一個記錄))將會使所有鏈接變得困難，而且只能在16核-HT中測量，而在32核中表現很差..但是任何如Point-Select測試的工作量將在所有MySQL內部構件一起工作是會讓你看到可能達到最大的性能(開始用SQL解析器，終止與取行值)..在你給定的MySQL版本和給定的HW配置下，這也可能達到最大SQL 查詢/每秒(QPS)率。

在Mysql5.6上我們獲得的最佳結果是25萬個查詢每秒，這也是那段時間Mysql/InnoDb上使用SQL語句查詢得到的最好的結果了。

當然，只有在使用‘只讀事務'功能才能達到這么高速度（Mysql5.6上的新功能）；另外，需要使用AUTOCOMMIT=1，否則CPU就會被輕易地浪費在啟動事務、提交事務上，你會實際上損失系統的整體性能。

因此，在Mysql5.7上介紹的第一個改進是‘只讀事務的自動發現'（實際上每個InnoDb事務都被認為是只讀的直到有一個DML聲明在此之外）功能---，這很大程度上簡化了只讀事務功能，節省了用戶和開發者的時間，他們不用再去管理是否采用只讀事務功能。但是，使用這個功能你仍然不能達到Mysql潛在的最佳每秒查詢率，因為CPU時間還是浪費在事務的開啟、結束狀態處理過程當中。

同時，Percona用不同的的方案來解決“事務列表”管理(TRX-列表)及在InnoDB中trx_sys互斥鏈接慢的問題。Percona的解決方案在用事務處理Point-Selects高負載時能表現良好，但MySQL5.7表現一般(但我不會公布5.7的結果，因為它的代碼不公開)...所以，至少我現在可以做一些比較：