MySQL内存临时表大小由tmp_table_size与max_heap_table_size二者较小值决定，必须设为相同值（如128M），否则仍触发磁盘落盘；单位仅支持M，配置后需重启或SET GLOBAL生效，并通过SHOW VARIABLES验证。
MySQL 本身不提供单独限制 MyISAM 临时表内存占用的参数——它用的是通用临时表机制，而 MyISAM 仅作为磁盘临时表的存储引擎之一，其内存部分由 tmp_table_size 和 max_heap_table_size 共同控制，且只对“内存临时表”生效；一旦超出阈值，MySQL 就会自动切换到磁盘临时表（可能用 MyISAM 或 InnoDB，取决于版本和配置），此时已不走内存限制逻辑。
为什么没有专门的 myisam_tmp_table_size 参数
MyISAM 不是 MySQL 内部临时表的默认内存引擎。内存临时表统一使用 internal_tmp_mem_storage_engine（MySQL 8.0.13+ 默认为 TempTable，非 MyISAM）；只有当内存不足或不满足条件时，才退化为磁盘临时表，这时才可能用到 MyISAM（5.7 及更早默认，8.0+ 默认改用 InnoDB）。所以不存在“限制 MyISAM 临时表内存”的需求，因为 MyISAM 根本不跑在内存里。
- 你看到的
Created_tmp_disk_tables增长，不代表用了 MyISAM：MySQL 8.0+ 默认用innodb_temp_data_file_path下的临时表空间，底层是 InnoDB 表 -
myisam_data_pointer_size、myisam_max_sort_file_size等参数只影响显式CREATE TABLE ... ENGINE=MyISAM的行为，和内部临时表无关 - 试图通过调小
key_buffer_size来“限制 MyISAM 临时表内存”完全无效——该参数只缓存 MyISAM 索引，不参与临时表分配
真正要调的是 tmp_table_size 和 max_heap_table_size
这两个参数决定查询中隐式创建的内存临时表（如 GROUP BY、ORDER BY、UNION 中间结果）能吃多少内存。只要它们设得低，就会更快触发落盘——而落盘后用什么引擎，由 MySQL 自动选，你无法指定 MyISAM。
- 必须同时设置且值相等：
tmp_table_size = 128M和max_heap_table_size = 128M，否则以较小者为准 - 单位只认
M（不是MB），写成128MB会导致配置加载失败，值回退到默认 16M - 修改后必须重启 MySQL（配置文件方式）或执行
SET GLOBAL（仅对新连接生效） - 验证是否生效：
SHOW VARIABLES LIKE 'tmp_table_size';和SHOW VARIABLES LIKE 'max_heap_table_size';必须返回完全一致的数值
如何确认你的查询是否被迫用了磁盘临时表
别猜引擎类型，看行为指标和执行计划：
- 监控状态变量：
SHOW STATUS LIKE 'Created_tmp_disk_tables';持续上涨，且Created_tmp_disk_tables / Created_tmp_tables > 0.2，说明大量落盘 - 查慢查询执行计划：
EXPLAIN FORMAT=JSON中出现"using_temporary_table": true，再结合"access_type": "ALL"或"using_filesort": true，基本可判定中间结果撑爆内存 - 注意强制落盘场景：哪怕参数设到 512M，只要查询含
TEXT/BLOB字段、GROUP BY列无索引、或VARCHAR(2000)这类宽字段，MySQL 仍会跳过内存表直接建磁盘临时表 -
SELECT @@internal_tmp_mem_storage_engine;查当前内存临时表引擎（TempTable或MEMORY），不是 MyISAM
真正关键的不是“怎么限 MyISAM”，而是“怎么让查询少落盘”。参数只是开关，根子在 SQL 写法和索引设计上——比如给 GROUP BY 字段加联合索引，比把 tmp_table_size 调到 1G 更治本。配置调得再细，也救不了没索引的 ORDER BY name。
