MySQL 8.0.16+ 升级后临时表空间膨胀主因是 TEMPTABLE 引擎启用且 internal_tmp_mem_storage_engine 未正确设为 TEMPTABLE；需先查版本和该变量值，确认 ≥8.0.13 且返回 TEMPTABLE，否则配置无效。

确认 internal_tmp_mem_storage_engine 当前值和版本兼容性

MySQL 8.0.16 起默认用 TEMPTABLE，但升级后可能仍沿用旧配置或误设为 MEMORY。不验证就调参，等于在错误基础上优化。

先执行：
SELECT VERSION(); —— 确保 ≥ 8.0.13（TEMPTABLE 最低支持版本）
SELECT @@internal_tmp_mem_storage_engine; —— 若返回 MEMORY 或空，说明未生效

• 从 5.7 升级上来的实例，配置文件里残留的 tmp_table_size 会被静默忽略，不报错也不警告
• SHOW VARIABLES LIKE 'tmp_table_size'; 在 8.0 中查不到或返回 0，这不是 bug，是已被移除
• 若版本 internal_tmp_mem_storage_engine = TEMPTABLE 会导致启动失败

显式配置 TEMPTABLE 并联动关键参数

即使默认已是 TEMPTABLE，也必须在配置文件中明确声明，并与 max_heap_table_size、temptable_max_ram 协同调整——单点修改基本无效。

在 my.cnf 的 [mysqld] 段添加：

Mysql Skill 1.0.0 (3)

MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。

下载

internal_tmp_mem_storage_engine = TEMPTABLE
max_heap_table_size = 268435456
temptable_max_ram = 1073741824

• max_heap_table_size 和 temptable_max_ram 不要设成相同值：前者控制单会话内存上限，后者是 TEMPTABLE 内部内存池总配额；建议 temptable_max_ram ≥ max_heap_table_size
• temptable_use_mmap = OFF 在容器或内存受限环境必须加，否则 mmap 占用虚拟地址空间易引发 OOM
• 重启 MySQL 才生效；在线 SET GLOBAL 只改 max_heap_table_size，不能改引擎

避免把 tmp_table_size 当调优目标

tmp_table_size 在 MySQL 8.0 中已彻底移除。把它当调优入口，90% 的人会卡在“为什么设了不生效”上。

• 临时表是否落盘，只取决于 max_heap_table_size 和 temptable_max_ram 中的较小值，以及查询是否含 TEXT/BLOB 字段
• max_heap_table_size 是 per-session 的，200 并发 × 256MB = 50GB 内存理论峰值，别按服务器总内存硬算
• 盲目调大 max_heap_table_size 可能导致高并发下内存争抢加剧，TEMPTABLE 的轻量锁优势反被抵消

验证是否真生效，而不是看参数“设对了”

参数写进配置、MySQL 重启成功 ≠ 优化落地。很多问题出在“老连接沿用旧会话参数”，或 SQL 本身触发了引擎降级。

执行一个典型 GROUP BY 查询后，立即运行：

SHOW STATUS LIKE 'Created_tmp%';

• 重点关注 Created_tmp_disk_tables / Created_tmp_tables 比值：持续 > 5% 就该干预
• EXPLAIN FORMAT=TREE 中出现 Using temporary 不代表一定落盘；要结合 information_schema.innodb_temp_table_info 查元数据，确认是否生成了 TEMPTABLE 类型的临时表
• 如果查询含 SELECT * + TEXT 字段，即使内存充足，TEMPTABLE 也会自动 off-page 管理，不报错但实际走磁盘页 —— 这类细节容易被监控忽略