ibtmp1暴涨是因TEMPTABLE引擎内存池满后直写临时表空间，需修改temptable_max_ram并重启；tmpdir未满且lsof查不到文件属正常，因数据不经过/tmp；该参数不支持运行时修改，必须配置后重启，并同步调整tmp_table_size与max_heap_table_size。
升级 MySQL 8.0 后 ibtmp1 持续暴涨，不是 tmpdir 满了，而是 TEMPTABLE 引擎的内存池被默认值卡死——必须改 temptable_max_ram，且不能运行时修改。
为什么 ibtmp1 疯涨却查不到 /tmp 写满？
MySQL 8.0.16+ 默认启用 internal_tmp_mem_storage_engine = TEMPTABLE，它不再受 tmp_table_size 和 max_heap_table_size 控制，而是独占一个内存池：temptable_max_ram。超限后直接写入 InnoDB 临时表空间 ibtmp1，不经过 tmpdir。所以：
-
lsof +D /tmp查不到大文件是正常的，数据根本没走那里 - 错误日志里报
The table '/tmp/#sql-xxx' is full是误导路径，真实落盘位置就是ibtmp1 -
SHOW GLOBAL STATUS LIKE 'Created_tmp_disk_tables'飙升，但Created_tmp_tables增长更猛，说明大量临时表在内存阶段就失败了
如何安全修改 temptable_max_ram？
这个参数不支持 SET GLOBAL，必须写进配置文件，并重启生效。操作前先确认当前值：
SELECT @@temptable_max_ram;
常见误操作是只调 tmp_table_size 却忽略它——完全无效。实操要点：
- 在
/etc/my.cnf的[mysqld]段添加：temptable_max_ram = 4G（MySQL 8.0.23+ 支持单位缩写；旧版本请写4294967296） - 物理内存 ≥ 128 GiB 可设为
6G，但绝不可超过物理内存的 15%，否则可能触发系统 OOM - 重启前务必执行：
SET GLOBAL innodb_fast_shutdown = 0;，再SHUTDOWN;，确保旧ibtmp1能被安全删除 - 搭配
innodb_temp_data_file_path = ibtmp1:12M:autoextend:max:10G，防无限制增长
tmp_table_size 和 max_heap_table_size 还得同步设对
哪怕你已经调高了 temptable_max_ram，老式 MEMORY 引擎逻辑依然存在——比如某些 GROUP BY、ORDER BY 场景仍会 fallback 到 MEMORY，这时就又回到“双参数取小值”的规则。
- 两个值必须显式设成完全相等，例如都为
256M；写成268435456字节更稳妥 - 重启后验证：
SELECT @@tmp_table_size, @@max_heap_table_size;，返回值必须一致 - 混跑 OLTP + 报表的实例，建议上限 ≤ 物理内存的 20%，比如 64 GiB 机器最多设
12G，但要注意并发连接数 × 该值后的总内存占用
参数只是兜底，SQL 才是根因
再大的 temptable_max_ram 和 tmp_table_size，也拦不住硬伤 SQL。EXPLAIN 出现 Using temporary 且没走索引，基本等于主动申请落盘。
-
GROUP BY或ORDER BY字段未覆盖索引最左前缀 → 补联合索引 - 用
JSON_EXTRACT(col, '$.field')、UPPER(name)或函数包裹字段分组 → 改写逻辑或加生成列索引 -
SELECT *+ 大结果集排序 → 改为只取必要字段 +LIMIT - 监控
Created_tmp_disk_tables / Created_tmp_tables比值，持续 > 5% 就该介入分析
真正棘手的是那些“参数调了、SQL 也改了，但某几个报表查询仍反复撑爆 ibtmp1”的情况——它们往往隐含多层子查询嵌套、窗口函数中间态爆炸或 JSON 数组展开，这类问题必须结合 EXPLAIN FORMAT=TREE 和慢查日志逐层拆解，没法靠单一配置解决。
