ibtmp1不收缩是因innodb仅在重启时重建且需满足三个前提：innodb_fast_shutdown=0、无长事务、无句柄占用；改innodb_temp_data_file_path仅影响新文件，旧文件必须重启释放；真正生效参数是temptable_max_ram、max_heap_table_size（须等值）和internal_tmp_mem_storage_engine=temptable。
MySQL升级后临时表空间（ibtmp1）不收缩，不是配置漏了或参数没开，而是InnoDB根本不支持在线收缩——它只在实例重启时重建，且必须满足三个硬性前提：innodb_fast_shutdown = 0、无长事务、ibtmp1未被其他进程句柄占用。
为什么innodb_temp_data_file_path改了也没用
这个参数只在MySQL启动时生效，用于定义新ibtmp1的初始大小和上限（如ibtmp1:12M:autoextend:max:5G），对已膨胀的旧文件完全无效。你看到ibtmp1涨到80GB，删表、杀连接、FLUSH TABLES全都没用，因为InnoDB不会回收已分配的空间。
- 直接
rm -f ibtmp1会导致重启失败，报错Cannot find undo tablespace（错误日志里常混写，实际指临时表空间） -
ALTER TABLESPACE ibtmp1 ENGINE=InnoDB语法合法但静默无效，文档未支持，别试 - 只调
tmp_table_size没用——MySQL 8.0已移除该参数，查SELECT @@tmp_table_size会返回0或报错
真正起作用的三个参数必须同步配对
MySQL 8.0.16+ 的临时表行为由temptable_max_ram主导，但它和max_heap_table_size、internal_tmp_mem_storage_engine共同决定内存使用边界。三者不一致就会导致部分查询fallback到磁盘，加剧ibtmp1膨胀。
-
temptable_max_ram：TEMPTABLE引擎总内存池上限，默认是物理内存3%（上限4GiB），不支持SET GLOBAL，必须写进配置文件并重启 -
max_heap_table_size：控制MEMORY表和部分临时表内存上限，必须与temptable_max_ram设为相同值（单位字节），否则取小值生效 -
internal_tmp_mem_storage_engine = TempTable：MySQL 8.0默认值，不建议改回MEMORY，否则丢失BLOB支持且更耗内存
示例配置（/etc/my.cnf）：
[mysqld] temptable_max_ram = 4294967296 max_heap_table_size = 4294967296 internal_tmp_mem_storage_engine = TempTable innodb_temp_data_file_path = ibtmp1:12M:autoextend:max:10G
重启前必须完成的三步动作
跳过任意一步，重启后ibtmp1仍保留原大小，甚至可能启动失败。
- 执行
SET GLOBAL innodb_fast_shutdown = 0（需SUPER权限，且实例不能为只读） - 确认无运行超600秒的事务：
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 600 - 执行
FLUSH TABLES，确保所有脏页落盘，避免shutdown时卡在刷盘阶段
做完再SHUTDOWN，等进程彻底退出，再systemctl start mysqld。此时MySQL会自动删除旧ibtmp1并按innodb_temp_data_file_path重建一个12MB的新文件。
怎么确认问题真出在临时表空间
别一看到磁盘满就调参。先验证是不是ibtmp1本身在撑爆根分区：
- 查真实路径：
SELECT @@innodb_temp_tablespaces_dir（默认是数据目录），然后ls -lh /var/lib/mysql/ibtmp1 - 看状态比值：
SHOW GLOBAL STATUS LIKE 'Created_tmp_disk_tables'÷Created_tmp_tables，超过15%说明大量查询被迫落盘 -
lsof +D /tmp查不到大文件？正常——8.0.16+的ibtmp1不走/tmp，它直写InnoDB临时表空间
真正棘手的是那些隐式触发TEMPTABLE的SQL：比如GROUP BY DATE(created_at)（函数导致索引失效）、UNION去重、多字段DISTINCT含TEXT列。参数只是兜底，SQL才是根因。
