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 引擎更稳。

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

性能影响明显：在含 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 进程内，任何绕过重启的“热清理”尝试，基本都等于在赌运气。