sort_buffer_size, Sort_merge_passes關係

對於事務性工做負載是一般最快這個大小設置爲32K，而且也是容許的最小尺寸。您應該謹慎使用它設置爲較大的值，由於這能夠很容易地下降性能。

若是全部的數據進行排序不適合在指定緩衝區大小的MySQL第一種類儘量多的數據將適合，那批寫入磁盤。接下來，它排序另外一批和寫入操做。而後執行這些和所需的全部其餘批次的基於磁盤的歸併排序，使用磁盤的三個臨時文件這一點。這個過程是有效的，但對於大型查詢可使用SET SESSION sort_buffer_size = 128 * 1024用於增長查詢運行sort_buffer_size的值以前的會話;例如使用128K的排序緩衝器。 * 1024是有方便，由於交互式客戶端不支持k或m後綴，能夠在配置文件中使用。

在基於磁盤的排序方法中使用合併的數量被報告在狀態變量Sort_merge_passes，購自SHOW GLOBAL STATUS; 。若是在正常生產中使用一段時間後，所報告的值是0能夠確定的是sort_buffer_size的值值不是過小，一個很好的跡象，這極可能是太大。在實踐中人們每每將其設置爲比最佳的許多工具更大的不恰當建議增長它的值。不要只是sort_buffer_size的值增長，直到Sort_merge_passes是0。這幾乎確定會產生大小比最快的代價大得多。對於很是魯莽，力求有一個繁忙的服務器上每正常運行時間的第二個至少幾Sort_merge_passes。可能還有更多。爲了更準確，你須要你的標杆查詢和建議結合你的實際。

對於常見的Linux內存分配方法用於分配存儲器能夠改變到較慢的方法超過256K 512K或和2M的尺寸。纔去對這些閾值之一，您應該使用特別注意，內存分配成本可能大大超過恰好低於閾值。

運行基準建議只讀或大部分工做負載能夠期待在Linux上使用一個32K sort_buffer_size的值，而不是256K 有 1-2％的性能提高。更大的尺寸比256K將有更大的反作用。好處將取決於使用的操做系統的內存分配器不一樣，但要以此爲約極可能是適當的值很好的指導。

MySQL的5.6有LIMIT的查詢只保留目前匹配緩衝限位行的優化。這避免了須要排序的整個結果集。若是您使用較大的排序緩衝區，以提升速度，通過的LIMIT查詢可能會發現再也不是有幫助的。

配置文件和服務器默認常用比用於事務處理的最優值更大的值。這樣的值能夠提升查詢效率低下的表現，這是可能的，做爲臨時措施可能會發現一個或兩個有用的MB的值，直到可以識別並調整涉及到的查詢。若是實際應該運行查詢，而不是設置全局值，使全部其餘查詢那種小數據量的慢以前設置會話值。

 

Linux的glibc的malloc的內部變量
在256K或512K的閾值是MALLOC_MMAP_THRESHOLD，其中的glibc malloc的從使用其堆使用MMAP改變點。這種規模以後分配時間能夠大約慢40倍。全部會話緩衝受此影響，不僅是排序緩衝器。

用glibc 5.4.23 malloc的調節變量在這些環境變量暴露開始：

MALLOC_TRIM_THRESHOLD_
MALLOC_TOP_PAD_
MALLOC_MMAP_THRESHOLD_
MALLOC_MMAP_MAX_
MALLOC_CHECK_

在極少數狀況下，會發現啓動MySQL調整如何釋放malloc的內存以前是很是有用的調整一個或多個的這些。咱們不建議這樣的正常使用，只有當找到的默認方式有些不常見的問題是malloc的適用於特定工做負載。