[導讀] 本文提供MySql5 7實現每秒50W查詢一文的細節以及基準測試結果，解釋了我早期在Mysql Connect 發表的談話。回顧MySQL InnoDB 的改善歷史。你能很容易發現。在MySQL 5 6穩定版本中從來沒有在read-only這麼
本文提供 MySql5.7實現每秒50W查詢 一文的細節以及基準測試結果，解釋了我早期在Mysql Connect 發表的談話。
回顧 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，trx_sys和lock_sys(InnoDB)
同時，Percona用不同的方案來解決「交易清單」管理(TRX-列表)及在InnoDB中trx_sys互斥連結慢的問題。 Percona的解決方案在用事務處理Point-Selects高負載時能表現良好，但MySQL5.7表現一般(但我不會公佈5.7的結果，因為它的程式碼不公開)...所以，至少我現在可以做一些比較：
觀察：
上面的測試是保持MySQL5.6始終執行在16核上，然後是16芯-HT,32核，32芯-HT.
而在MySQL5.7上做同樣的測試卻看起來大有不同，因為在5.7中lock_sys互斥鏈接的時間段已經很低了，同時trx_sys互斥相關代碼也得到第一次變化的情形：
同時，我們繼續與建議用其他方式管理TRX列表的Percona團隊交換了意見，他們的方案看起來非常有趣，不過在5.5上，這樣的代碼卻不能展示出更高的每秒可進行的查詢數（QPS），而且在5.6上的這樣程式碼（曾經測試過Percona Server 5.6）最大的每秒可進行的查詢數（QPS）也不會比在MySQL 5.6上大。然而，討論涉及到一個有趣的觀點：如果同時有一些讀寫負載在運行的話，它對只讀性能有什麼影響？ ……而且，即使在同樣的測試條件下MySQL 5.7程式碼仍然運行的要好一些，效果是非常明顯的（你可以在這裡查看我的分析，然而，再次說明一下，這段時間內我不能展示５ .7上的結果，因為它的程式碼還沒有對大眾公佈－也許會在以後的一篇文章中給出）..
由於這兒同時對任何純粹的讀寫負載也有影響，因此有足夠的動機以Sunnys很長一段時間所期待的那樣重新寫整個TRX清單相關的程式碼，然而，這種經歷簡直讓人痴迷！
;-)) 日復一日，我們很高興的看到我們的每秒可進行的查詢圖逐漸變高，直到在同一個32核的超線程伺服器上達到了每秒可進行的查詢440K!
5.7開發里程碑發布2上進行的Select 8個表所得到的結果數：
观察结果：
通过Sysbench降低了CPU的使用率。
在MySQL服务器上具有更高的CPU可用性。
我们实现了50万每秒查询。
还有什么呢？
我可能只提到：kudos Sunny和整个MySQL的开发团队；
让我们看一下现在选择8张表工作负载的情况下的最大每秒查询。
MySQL-5.7.2 (DMR2)
MySQL-5.6.14
MySQL-5.5.33
Percona Server 5.6.13-rc60.5
Percona Server 5.5.33-rel31.1
MariaDB-10.0.4
MariaDB-5.5.32
每个引擎都在以下配置下进行测试：
CPU taskset: 8核-HT,16核，16核-HT,32核，32核-HT
并发会话数：8，16，32 ... 1024
InnoDB自旋等待延时：6，96
最好的结果是来自任意两个特定的组合间的比较。通过对数据库引擎的比较，我得到了下面的一个图表，这个图表我在以前的文章中已经提到过了。
下面是一些评论：
对Mysql5.7的巨大差距结果不需要做过多的评论，因为这是很明显的。
那么，有趣的是基于MySQL5.5的代码库引擎没有任何的接近MySQL5.6的结果。
这已经证实了在使用MySQL5.6的代码库引擎之后，Percona Server达到了MySQL5.6的水平，然而MariaDB-10仍然还在探索的路上。
因此，毫无疑问，MySQL5.6是代码的基石!
MySQL5.7是在MySQL5.6基础上的再一次优化扩展。
具有什么样的扩展性呢？
答案是简单的：MySQL5.7是唯一在此基础上进行扩展的。
如果使用ip端口和一个重量级的Sysbench-0.4.13，会得到如下的结果：
QPS只是稍微的略低一点，但是总体的趋势是完全一样的。
可扩展性也是非常的相似：
更多的结果将会出来，敬请期待；
注意：对一个单表绑定过多的工作负载是不好的：
减少InnoDB间的争论使得其他的争论更加的明显。
当负载是绑定在一张单表上时候，MDL的争论将变得更加主导。
这是预期希望的，我们在下一个DMRS上将保持不变。
还有很多挑战摆在我们面前;-)
作为参考，我上述测试的硬件配置信息如下：
Server : 32cores-HT (bi-thread) Intel 2300Mhz, 128GB RAM
OS : Oracle Linux 6.2
FS : 启用"noatime,nodiratime,nobarrier"挂载的EXT4
my.conf:
max_connections=4000 key_buffer_size=200M low_priority_updates=1 table_open_cache = 8000 back_log=1500 query_cache_type=0 table_open_cache_instances=16 # files innodb_file_per_table innodb_log_file_size=1024M innodb_log_files_in_group = 3 innodb_open_files=4000 # buffers innodb_buffer_pool_size=32000M innodb_buffer_pool_instances=32 innodb_additional_mem_pool_size=20M innodb_log_buffer_size=64M join_buffer_size=32K sort_buffer_size=32K # innodb innodb_checksums=0 innodb_doublewrite=0 innodb_support_xa=0 innodb_thread_concurrency=0 innodb_flush_log_at_trx_commit=2 innodb_max_dirty_pages_pct=50 innodb_use_native_aio=1 innodb_stats_persistent = 1 innodb_spin_wait_delay= 6 / 96 # perf special innodb_adaptive_flushing = 1 innodb_flush_neighbors = 0 innodb_read_io_threads = 4 innodb_write_io_threads = 4 innodb_io_capacity = 4000 innodb_purge_threads=1 innodb_adaptive_hash_index=0 # monitoring innodb_monitor_enable = '%' performance_schema=OFF
如果你需要的话，Linux Sysbench的二进制版本在这里：
Sysbench-0.4.13-lux86
Sysbench-0.4.8-lux86
使用UNIX socket来运行Point-Selects测试的Sysbench命令如下（在parallel中启动8个进程）：
LD_PRELOAD=/usr/lib64/libjemalloc.so /BMK/sysbench-0.4.8 --num-threads=$1 --test=oltp --oltp-table-size=10000000 \
--oltp-dist-type=uniform --oltp-table-name=sbtest_10M_$n \
--max-requests=0 --max-time=$2 --mysql-socket=/SSD_raid0/mysql.sock \
--mysql-user=dim --mysql-password=dim --mysql-db=sysbench \
--mysql-table-engine=INNODB --db-driver=mysql \
--oltp-point-selects=1 --oltp-simple-ranges=0 --oltp-sum-ranges=0 \
--oltp-order-ranges=0 --oltp-distinct-ranges=0 --oltp-skip-trx=on \
--oltp-read-only=on run > /tmp/test_$n.log &使用IP端口来运行Point-Selects测试的Sysbench命令如下（在parallel中启动8个进程）：
LD_PRELOAD=/usr/lib64/libjemalloc.so /BMK/sysbench-0.4.13 --num-threads=$1 --test=oltp --oltp-table-size=10000000 \
--oltp-dist-type=uniform --oltp-table-name=sbtest_10M_$n \
--max-requests=0 --max-time=$2 --mysql-host=127.0.0.1 --mysql-port=5700 \
--mysql-user=dim --mysql-password=dim --mysql-db=sysbench \
--mysql-table-engine=INNODB --db-driver=mysql \
--oltp-point-selects=1 --oltp-simple-ranges=0 --oltp-sum-ranges=0 \
--oltp-order-ranges=0 --oltp-distinct-ranges=0 --oltp-skip-trx=on \
--oltp-read-only=on run > /tmp/test_$n.log &
愿你有所收获，
-Dimitri
以上就是 MySQL性能：使用 MySQL 5.7 实现每秒 50 万查询的内容，更多相关内容请关注PHP中文网（www.php.cn）！
