innodb_temp_data_file_path用于配置InnoDB共享临时表空间文件ibtmp1的位置、初始大小及自动扩展行为，仅控制全局临时表空间，不管理会话级临时表文件；默认创建12MB可无限增长的ibtmp1，重启前不缩容，需停库后按ibtmp1:12M:autoextend:max:2G格式配置。
innodb_temp_data_file_path 是干啥的？
innodb_temp_data_file_path 控制的是 InnoDB 的「共享临时表空间」文件（即 ibtmp1）的位置、初始大小和自动扩展行为。它只影响一个文件：MySQL 启动时创建的全局共享临时表空间，不控制 session 级别的 .ibt 文件（那些由 innodb_temp_tablespaces_dir 管理）。
这个参数在 MySQL 5.7 引入，8.0 默认启用；如果你没显式配置，MySQL 会自动创建一个初始 12MB、可无限增长的 ibtmp1。但一旦涨到几十 GB，重启前它不会缩容——这是最常被忽略的点。
怎么安全地设置 innodb_temp_data_file_path
修改前必须停库，且不能在运行中动态生效。配置格式为：
innodb_temp_data_file_path = ibtmp1:12M:autoextend:max:2G
其中关键部分：
-
ibtmp1是固定文件名，不可改 -
12M是初始大小，建议保持默认或略增（如 50M），太小会导致频繁扩展 IO 必须保留，否则空间用尽会报错 Operating system error number 28 in a file operation-
:max:2G是硬上限，强烈建议设置——防止磁盘被撑爆。注意：达到 max 后，涉及磁盘临时表的查询会直接失败，错误类似Internal temporary table is full
配置写入 my.cnf 的 [mysqld] 段后，需彻底关闭 MySQL（systemctl stop mysqld），删除旧 ibtmp1（它不在数据目录里，就在 datadir 下），再启动。
为什么改了还是看到 ibtmp1 越长越大？
即使设置了 :max:2G，ibtmp1 仍可能长期维持在高位，原因很实在：
- MySQL 不会在空闲时自动收缩
ibtmp1，哪怕所有临时表都已释放 - 只有完全重启（非 reload）才能重置文件大小回初始值
- 如果业务中有长事务或未提交的 DML，临时表空间可能被隐式占用，导致无法释放
- 监控时别只看文件大小，用
SELECT * FROM information_schema.INNODB_TEMP_TABLE_INFO;查当前活跃的内部临时表更准
该不该用 innodb_temp_data_file_path？还是换 session 临时表空间？
对大多数线上环境，更推荐弱化 ibtmp1 的角色，转而依赖 session 级临时表空间（MySQL 8.0.13+）：
- 把
innodb_temp_data_file_path设成小而稳的值，比如ibtmp1:12M:autoextend:max:512M - 确保
innodb_temp_tablespaces_dir指向一块独立、有足够空间的磁盘（如/data/innodb_temp） - session 临时表空间（
.ibt文件）在连接断开后立即 truncate，不会残留膨胀 - 避免把所有鸡蛋放在
ibtmp1这一个篮子里——它挂了整个实例就无法创建磁盘临时表
真正难处理的从来不是“怎么设参数”，而是查不出哪个慢查询在疯狂生成 200MB 的排序临时表。先用 performance_schema.events_statements_history_long 定位罪魁，再调参，不然永远在救火。
