myisam排序总写磁盘临时表是因为其不管理内存临时表，依赖mysql server层的memory引擎，一旦超tmp_table_size与max_heap_table_size较小值、排序字段无索引或类型不匹配，即落盘为myisam格式磁盘表；需同步配置两参数并确保索引覆盖排序字段。
MyISAM排序为什么总写磁盘临时表
MyISAM引擎本身不管理内存临时表——它只管索引和数据文件，ORDER BY或GROUP BY的中间结果全靠MySQL Server层用MEMORY引擎临时存。一旦触发落盘条件（比如字段含TEXT、排序列没索引、或tmp_table_size被卡死），就直接落到@@tmpdir下生成MyISAM格式的磁盘临时表，而不是InnoDB那种可配置的ibtmp1。
tmp_table_size和max_heap_table_size必须设相等
很多人只改tmp_table_size，忘了max_heap_table_size还卡在默认16MB。MySQL实际取两者较小值，所以哪怕你配了tmp_table_size = 512M，只要max_heap_table_size = 16777216（即16MB），所有超16MB的排序都会强制落盘。
- 在
/etc/my.cnf的[mysqld]段里显式写两行：tmp_table_size = 268435456和max_heap_table_size = 268435456（即256MB，单位必须是字节，别写M/G） - 重启前务必执行
SHOW VARIABLES LIKE 'tmp_table_size';和SHOW VARIABLES LIKE 'max_heap_table_size';确认数值完全一致 - 混跑OLTP+报表的实例，建议按单条峰值SQL的中间结果估算：查
EXPLAIN FORMAT=JSON里的estimated_row_count × avg_row_length，再留30%余量，但别超物理内存20%
排序字段没索引 or 类型不匹配 = 白调参数
ORDER BY是否走内存临时表，不取决于数据量大小，而取决于能否用索引完成排序。MyISAM对索引依赖极强，一旦type=ALL或key=NULL，就必然物化全表再排序。
- 确保
ORDER BY字段有单列索引或联合索引最左前缀覆盖，例如ORDER BY status, created_at要建INDEX idx_status_time ON tbl (status, created_at) - 避免隐式类型转换：
WHERE user_id = '123'（字符串）对比BIGINT字段，会导致索引失效，排序被迫全表扫描 - 别在
ORDER BY里用函数，如ORDER BY UPPER(name)或DATE(created_at)——MyISAM无法利用索引加速，直接落盘 -
SELECT *+ORDER BY极易溢出：大字段（TEXT、BLOB）会被拖进排序，哪怕只显示几列；改成明确列名，剔除冗余字段
MyISAM表本身不适合大数据量排序
MyISAM没有MVCC、不支持行锁、排序时会锁整个表，且临时表落盘后无法像InnoDB那样通过innodb_temp_data_file_path限流。一旦Created_tmp_disk_tables持续上涨，说明架构层已到瓶颈。
- 优先考虑把该表迁到InnoDB：支持在线DDL、更优的缓冲池管理、且
innodb_tmpdir可单独挂SSD - 若必须保留MyISAM，对高频排序场景加
SET SESSION sort_buffer_size = 4M;（别全局设，防连接数多时OOM） - 观察
SHOW GLOBAL STATUS LIKE 'Created_tmp_disk_tables';与Created_tmp_tables比值，超15%就得干预——这不是参数问题，是查询路径问题
真正卡住的往往不是内存大小，而是排序逻辑是否能被索引覆盖。调参只是补救，换索引或换引擎才是根治。
