對於事務性工作負載是通常最快這個大小設置爲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的適用於特定工作負載。