MySQL内存临时表上限取tmp_table_size与max_heap_table_size中较小值，超限则落盘至ibtmp1；需同步调大二者，推荐64M～256M；InnoDB临时表空间应配置多文件固定大小以降低I/O争用；8.0.13+建议用TempTable引擎替代MEMORY。
临时表用的是 tmp_table_size 还是 max_heap_table_size？
MySQL 会同时检查这两个参数，取其中较小值作为内存临时表的上限。一旦查询生成的临时结果超过这个值，就会自动落地到磁盘（ibtmp1），性能陡降。
常见错误现象：SHOW PROCESSLIST 看到大量 Creating tmp table 状态，且查询变慢；SHOW STATUS LIKE 'Created_tmp%' 中 Created_tmp_disk_tables 持续增长。
- 两者必须同步调大，只改一个没用
- 默认值通常太小（比如 16MB），复杂 JOIN 或 GROUP BY 很容易触发磁盘临时表
- 若应用中存在大量排序或去重操作，建议设为 64M～256M，具体看可用内存和并发量
- 注意：该配置是会话级的，
SET SESSION tmp_table_size = 134217728可临时验证效果
为什么 innodb_temp_data_file_path 不能只配单个文件？
InnoDB 临时表空间（ibtmp1）默认是自动扩展的单一文件，但线上高并发场景下容易因频繁扩展、碎片、锁争用导致 I/O 延迟飙升。
使用场景：OLAP 类查询、大批量数据导入、窗口函数密集型分析任务。
- 推荐显式配置为固定大小 + 多个文件，例如：
innodb_temp_data_file_path = ibtmp1:12M:autoextend:max:2G;ibtmp2:12M:autoextend:max:2G - 每个文件独立分配和清理，降低元数据锁竞争
-
max:限制上限，防止磁盘被撑爆；不设的话可能无限增长直到填满分区 - 修改后需重启 MySQL 生效，且旧
ibtmp1文件不会自动删除，要手动清理（确保实例已干净关闭）
internal_tmp_mem_storage_engine 设成 MEMORY 还是 TempTable？
MySQL 8.0.13+ 引入了新引擎 TempTable，专为临时表优化，支持 BLOB、更高效压缩和并行扫描，比老式 MEMORY 引擎更稳。
性能影响明显：在含 JSON 字段或长文本的 GROUP BY 查询中，TempTable 内存占用可低 30%～50%，且不会因字段超限直接报错。
- 确认版本是否支持：
SELECT VERSION();≥ 8.0.13 才能用TempTable - 设为
TempTable后，tmp_table_size仍控制初始内存分配，但引擎内部可动态管理更多内存 - 若遇到
ER_TT_EXCEED_MEM_LIMIT错误，说明临时表超出temp_table_max_ram（默认 1GB），不是tmp_table_size - 兼容性注意：某些 UDF 或存储过程若硬编码依赖
MEMORY行为，切换前需测试
临时表空间文件（ibtmp1）占满磁盘怎么办？
这不是“删掉就能释放”的普通文件——它是 InnoDB 共享临时表空间，MySQL 运行时始终持有句柄，直接 rm 会导致实例崩溃。
真正有效的做法只有两个：等空闲 + 重启，但线上往往不能停。
- 先查是否真有活跃查询卡住临时表：执行
SELECT * FROM performance_schema.events_statements_current WHERE SQL_TEXT LIKE '%tmp%'; - 确认无长事务后，执行
SET GLOBAL innodb_temp_tablespaces_dir = '/new/path/';（8.0.16+ 支持运行时迁移） - 更稳妥的方式是安排维护窗口，停止写入 → 等待
SHOW ENGINE INNODB STATUS中 “TEMPORARY TABLES” 部分为 0 → 重启 - 监控建议：把
INFORMATION_SCHEMA.INNODB_TEMP_TABLE_INFO加入巡检 SQL，避免等到告警才发觉
临时表空间不像常规数据文件那样透明可控，它的生命周期绑定在 mysqld 进程内，任何绕过重启的“热清理”尝试，基本都等于在赌运气。
