MySQL 5.6 GA与5.5性能比较测试

田野

如果你还不清楚 MySQL 5.6 版本一长串的新特性和改进内容，可以从这里获得了解。

而我这篇文章的主要目的则是性能的测试。

我使用 Sysbench workloads (Read-Only/Read-Write) 来测试。下面是我的测试环境：

硬件配置:

服务器 : 32核 bi-thread (HT) Intel 2300Mhz, 128GB RAM

操作系统 : Oracle Linux 6.2

文件系统 : XFS mounted with "noatime,nodiratime,nobarrier,logbufs=8"

MySQL : 5.6-GA, latest 5.5

MySQL 配置:

1. #--------------------------------------------------  
   
2. max_connections = 4000  
   
3. 
   
4. key_buffer_size = 200M  
   
5. low_priority_updates = 1  
   
6. sort_buffer_size = 2097152  
   
7. back_log = 1500  
   
8. query_cache_type = 0  
   
9. 
   
10. # files  
    
11. innodb_file_per_table  
    
12. innodb_log_file_size = 1024M  
    
13. innodb_log_files_in_group = 3  
    
14. innodb_open_files = 4000  
    
15. table_open_cache = 8000  
    
16. table_open_cache_instances = 16  
    
17. 
    
18. # buffers  
    
19. innodb_buffer_pool_size = 32000M  
    
20. innodb_buffer_pool_instances = 32  
    
21. innodb_log_buffer_size = 64M  
    
22. join_buffer_size = 32K  
    
23. sort_buffer_size = 32K  
    
24. 
    
25. # tune  
    
26. innodb_checksums = 0  
    
27. innodb_doublewrite = 0  
    
28. innodb_support_xa = 0  
    
29. innodb_thread_concurrency = 0  
    
30. innodb_flush_log_at_trx_commit = 2  
    
31. innodb_flush_method = O_DIRECT  
    
32. innodb_max_dirty_pages_pct = 50  
    
33. innodb_use_native_aio =1  
    
34. innodb_stats_persistent = 1  
    
35. innodb_spin_wait_delay = 6 / 96  
    
36. 
    
37. # perf special  
    
38. innodb_adaptive_flushing = 1  
    
39. innodb_flush_neighbors = 0  
    
40. innodb_read_io_threads = 16  
    
41. innodb_write_io_threads = 4  
    
42. innodb_io_capacity = 2000  
    
43. innodb_purge_threads =1  
    
44. innodb_adaptive_hash_index =  1 / 0  
    
45. 
    
46. # Monitoring  
    
47. innodb_monitor_enable = '%'
    
48. performance_schema = ON
    
49. performance_schema_instrument = '%=on'
    
50. #--------------------------------------------------

复制代码

MySQL 调整:

配置最主要的不同是 AHI (innodb_adaptive_hash_index) 和 Spin Delay (innodb_spin_wait_delay) -- 而其他的部分在这个测试过程中基本上已经足够好了。
关于 AHI 的影响我之前已经写了很多文章。AHI 主要的困境在于“用还是不用”，在很多情况下它可以帮助因为锁导致的堵塞并加快索引的访问，但在高并发的情况下可能会因为其 btr_search_latch 导致 rw锁争用导致的瓶颈

在 MySQL 5.6 中的 Spin Delay 设置需要特别的注意，因为它在管理内部互斥量和 rw 锁争用时扮演非常重要的角色，利用它可能会让你轻松的将性能提升一倍。（你可以通过这里来了解详情，但你应该知道，没有银弹，也没有什么固定的最优值是适合各种不同的环境，这个完全依赖于你的系统负载。因此其默认值跟 MySQL 5.5 一样都是 6）。
因此，在我的测试中，我非常好奇想了解在不同的负载情况下最佳的 AHI 和 Spin Delay 设置的配置对。

接下来要记住 MySQL 5.5 和 5.6 在可伸缩性方面的限制。我在 8、16、32 和 64 核的情况下重新进行测试（64核相当于开启和超线程的32核机器，其他的都没有开启超线程）

本篇文章来源于 Linux公社网站(www.linuxidc.com)  原文链接：http://www.linuxidc.com/Linux/2013-04/82070.htm

xiangys0134

楼主叼叼的。。