对于事务性工作负载是通常最快这个大小设置为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的适用于特定工作负载。
