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.)