如果你的MySQL查询突然变慢，磁盘空间莫名其妙被撑爆，那很可能是临时表配置出了岔子。这里有一个关键结论：MySQL创建内存临时表时，生效的是`tmp_table_size`与`max_heap_table_size`二者中的**较小值**；必须将两者设为相同值（如64M～256M），否则仍会因阈值过低触发磁盘落盘，导致`ibtmp1`或`/tmp`撑爆。

tmp_table_size 和 max_heap_table_size 到底谁生效？

MySQL在创建内存临时表时，会同时检查两个参数——`tmp_table_size`和`max_heap_table_size`，然后取其中较小的那个作为实际上限。只调大其中一个，另一个还卡在默认的16MB，照样触发磁盘落盘。这种情况往往表现为：`SHOW PROCESSLIST`中持续出现`Creating tmp table`状态，查询变慢；同时`SHOW STATUS LIKE 'Created_tmp_disk_tables'`数值快速上升。默认值实在太保守（通常16MB），一个含`GROUP BY user_id, DATE(created_at)`的千万级订单聚合查询，很容易就超限了。 那怎么办？推荐的做法是将这两个参数设为相同的值：64M～256M。具体取值要看单次查询中间结果集大小和并发连接数——比如100个并发连接 × 128MB = 12.8GB内存占用，这个账得提前算清楚。如果想先验证效果，可以用会话级设置快速测试： ``` SET SESSION tmp_table_size = 134217728; SET SESSION max_heap_table_size = 134217728; ``` 然后观察`Created_tmp_disk_tables`是否明显下降。如果降了，说明问题就是参数不匹配。

为什么 innodb_temp_data_file_path 要配多个固定大小文件？

默认的`ibtmp1`是单文件、自动扩展模式，在高并发下极易因元数据锁争用、频繁扩展和碎片导致I/O延迟飙升——这不是普通的“慢”，而是“卡在系统层”。尤其在使用窗口函数密集分析、大批量导入、OLAP类报表查询的场景下，这个问题尤为突出。 必须显式配置为多文件 + 固定大小，并加上`max:`上限。例如： ``` innodb_temp_data_file_path = ibtmp1:12M:autoextend:max:2G;ibtmp2:12M:autoextend:max:2G ``` 每个文件独立分配和清理，能有效降低锁竞争；而`max:`上限能防止磁盘被撑爆——不加这个限制的话，文件可能无限增长直到填满分区。需要注意的是，修改配置后需重启MySQL才能生效，而且旧的`ibtmp1`不会自动删除，必须确保实例已干净关闭后再手动清理。

如何判断你的查询真正在用内存临时表？

别只看SQL里有没有`CREATE TEMPORARY TABLE`——MySQL内部自动创建的临时表才是性能瓶颈的主因，而且你完全看不到它们。关键监控指标是：`Created_tmp_tables`（总内存临时表数）与`Created_tmp_disk_tables`（磁盘临时表数）的比值。如果后者占前者的比例超过20%，说明大量查询被迫落盘了。 执行计划中间出现`Using temporary`（尤其配合`Using filesort`）是一个强信号。但要注意：即使没有这个提示，复杂`UNION`或嵌套`DISTINCT`也可能会暗中创建临时表。另外，TEXT/BLOB字段、未索引的`ORDER BY`、跨JOIN表的`GROUP BY`都会强制使用磁盘临时表——哪怕你把内存参数调得再大也没用。

MySQL 8.0.13+ 用户该用 TempTable 还是 MEMORY？

别再盲目地设`ENGINE=MEMORY`了。从8.0.13开始，MySQL默认启用`TempTable`存储引擎替代`MEMORY`，它支持BLOB/TEXT，行格式更紧凑，并发性能也更好。`TempTable`是默认且推荐的，无需显式指定。只有在明确需要HASH索引做等值查找时，才考虑`ENGINE=MEMORY`。 但要注意：`TempTable`仍然受`tmp_table_size`和`max_heap_table_size`的限制，超限一样会落盘。如果业务确实依赖`MEMORY`的HASH索引特性，记得在创建临时表时显式写上`ENGINE=MEMORY`，否则会被静默转成`TempTable`。 配置不是调完就完事了——真正容易被忽略的细节包括：临时表是否真的被复用（还是每次新建）、字段类型是否无意中触发了磁盘回退（比如VARCHAR(500)实际存了490字符）、以及并发连接数乘以单次内存上限后的总开销是否超出物理内存余量。这些细节不盯住，参数调得再大也白搭。