mysql sort 性能优化

http://dev.mysql.com/doc/refman/5.7/en/order-by-optimization.html

      这段时间mysql 数据库的性能明显下降,iowait达到了30, 响应时间明显变长.  经过show processlist 查看,发现有不少session在处理sort 操做, 跟DBA一块儿调试优化,增大sort_buffer_size 好象效果也不大, 经过查看监控,也没发现有硬盘排序. 我怀疑是sort致使性能降低,固让开发修改程序, sort由程序来处理. 星期五发布后,今天发现压力当然好了不少.

      所以基本上能肯定是sort引发的问题. 今天仔细分析问题,查看mysql的参数时,看到一个叫作max_length_for_sort_data 的参数, 值是1024 仔细查看mysql 的filesort算法时, 发现mysql的filesort有两个方法,MySQL 4.1以前是使用方法A, 以后版本会使用改进的算法B, 但使用方法B的前提是列长度的值小于max_length_for_sort_data, 但咱们系统中的列的长度的值会大于1024. 所以也就是说在sort的时候, 是在使用方法A, 而方法A的性能比较差, 也就解释了咱们的mysql系统在有sort时,性能差,去掉以后性能立刻提升不少的缘由.

立刻修改max_length_for_sort_data这个值，增大到8096, 果真性能就提升了.

  总结:

  mysql对于排序,使用了两个变量来控制sort_buffer_size和  max_length_for_sort_data, 不象oracle使用SGA控制. 这种方式的缺点是要单独控制,容易出现排序性能问题.

 

   对于filesort的两个方法介绍,以及优化方式,见

http://forge.mysql.com/wiki/MySQL_Internals_Algorithms

 Using the modified filesort algorithm, the tuples are longer than the pairs used in the original method,

and fewer of them fit in the sort buffer (the size of which is given bysort_buffer_size).

As a result, it is possible for the extra I/O to make the modified approach slower, not faster.

To avoid a slowdown, the optimization is used only if the total size of the extra columns in the sort tuple does not exceed the value of themax_length_for_sort_data system variable.

(A symptom of setting the value of this variable too high is that you should see high disk activity and low CPU activity.)