phpEnv中sort_buffer_size的实际配置路径是phpenv\mysql\my.ini，在[mysqld]段下设为整数（如1048576），修改后需重启MySQL服务；动态SET SESSION无效因短连接、版本限制或查询未触发排序。
phpEnv 里改 sort_buffer_size 的实际路径在哪
phpEnv 是 Windows 下的集成环境，MySQL 配置文件默认在 phpenv\mysql\my.ini（不是 my.cnf），你得先确认这个路径存在且被 MySQL 实际加载。常见误区是改了别的 my.ini（比如放在 C:\Windows 下）却没生效——MySQL 启动时只认它自己目录下的配置文件。
打开该文件，在 [mysqld] 段落下添加或修改：
sort_buffer_size = 1048576
注意：不要写成 1M 或 1MB，phpEnv 内置的 MySQL 版本（多为 5.7 或 8.0）只接受整数（单位字节），1048576 = 1MB。改完必须重启 phpEnv 的 MySQL 服务，否则不生效。
为什么 SET SESSION sort_buffer_size 不起作用
你在 PHP 里执行 SET SESSION sort_buffer_size = 1048576 看似成功，但很可能被忽略，原因有三：
立即学习“PHP免费学习笔记（深入）”；
- PHP 的 PDO/MySQLi 连接默认是“短连接”，每次查询后连接关闭，SESSION 设置随连接销毁而丢失；
- 某些 phpEnv 自带的 MySQL 版本（尤其旧版 5.6）对动态设置
sort_buffer_size支持不完整，SHOW VARIABLES显示已变，但实际排序仍走默认路径； - 如果查询本身能用索引覆盖排序（比如
ORDER BY indexed_col），MySQL 根本不进排序流程，调大这个值毫无意义。
验证是否真起作用：执行排序查询后，立刻查状态变量：SHOW STATUS LIKE 'Sort_merge_passes'。连续两次相同查询，若该值增加，说明触发了磁盘归并——这时再调大 sort_buffer_size 才有意义。
设成多大才算合理，而不是埋雷
phpEnv 通常跑在开发机或低配服务器上（8GB 内存常见），盲目设高反而容易崩：
- 每个需要排序的连接都独占一份
sort_buffer_size，不是共享的； - 默认值是 256KB，设成 4MB 后，20 个并发排序连接就吃掉 80MB；
- phpEnv 默认
max_connections = 100，若全连上来做排序，100 × 4MB = 400MB，加上innodb_buffer_pool_size（常设 512MB～1GB），很容易触发系统 swap； - 真实瓶颈往往不在这里：先看执行计划有没有用上索引排序（
type=range+Extra=Using index），没有的话加索引比调缓冲区快十倍。
建议起步值设为 1048576（1MB），观察 Created_tmp_disk_tables 和 Sort_merge_passes 是否下降；若无改善，大概率是查询本身没走内存排序，别硬调。
容易被忽略的配套参数
sort_buffer_size 不是单打独斗的，它和几个参数联动才决定最终排序行为：
-
max_sort_length：控制单行参与排序的最大字节数，默认 1024。如果你按TEXT字段排序，哪怕缓冲区够大，也会被截断导致排序不准； -
read_rnd_buffer_size：排序后回表读数据用的缓冲区，若排序后还要取其他字段（非覆盖索引），它太小会拖慢整体速度，建议与sort_buffer_size设为相同值； -
tmp_table_size和max_heap_table_size：如果GROUP BY或DISTINCT也涉及排序，这两个值太小会强制生成磁盘临时表，让sort_buffer_size白调； - 务必保持三者一致：
tmp_table_size = max_heap_table_size = 67108864（64MB），避免隐式降级。
最隐蔽的问题是：你调大了 sort_buffer_size，但 innodb_buffer_pool_size 太小，导致排序字段所在的索引页频繁换入换出——这时真正该加的是缓冲池，不是排序缓冲区。
