innodb_temp_data_file_path 是为防止 ibtmp1 无节制增长导致磁盘爆满而设的硬性上限控制手段，通过 max: 参数强制在达到阈值时报错退出而非继续写入，重启后文件重置释放空间，但不提升性能。
直接结论：innodb_temp_data_file_path 不是用来“优化大小”的，而是用来防止 ibtmp1 无节制暴涨撑爆磁盘的底线控制手段；它本身不提升性能，只避免崩溃。
为什么改 innodb_temp_data_file_path 能防磁盘爆满
MySQL 8.0+ 的 InnoDB 临时表空间（ibtmp1）默认自动扩展、**永不收缩**。一旦大排序、大 GROUP BY 或 JSON 函数触发落盘，它就一路涨到 max:XXG 上限，甚至卡在上限不动——但磁盘可能早被占满。报错 ERROR 1114 (HY000): The table '/data/mysql/tmp/#sql_...' is full 就是它在喊救命。
关键点在于：innodb_temp_data_file_path 中的 max: 限制的是单个文件上限，不是总空间；它不会阻止落盘，但能强制 MySQL 在达到上限时抛错退出，而不是继续写坏磁盘或阻塞所有连接。
- 没设
max:→ibtmp1可无限增长（直到磁盘满） - 设了
max:10G→ 到 10G 后新查询失败，但其他查询还能跑 - 重启 mysqld →
ibtmp1会被重建为初始大小（如 12MB），空间立刻释放
innodb_temp_data_file_path 的正确写法和常见错误
这个参数格式严格，空格、冒号、单位、路径都错不得。典型安全配置是：
innodb_temp_data_file_path = ibtmp1:12M:autoextend:max:20G
含义：起始 12MB，按需扩展，上限 20GB。
- ❌ 错误写法：
ibtmp1:20G—— 没autoextend，启动就分配 20G，浪费且无法动态伸缩 - ❌ 错误写法：
/var/lib/mysql/ibtmp1:12M:autoextend:max:20G—— 路径必须是文件名，不能带目录（目录由datadir决定） - ❌ 错误写法：
ibtmp1:12M:autoextend:max:20g—— 单位必须大写G，小写会忽略max导致失控 - ✅ 必须配合
innodb_temp_tablespaces_dir（8.0.30+）才能指定多路径分散 IO，但普通场景不用
改完参数后必须重启，且要盯住长事务
该参数是只读变量，修改 my.cnf 后必须重启 MySQL 才生效。但重启前务必确认没有运行超长事务，否则：
- 正在写的临时表数据会丢失，对应查询报错
- 若事务中含 DML，回滚可能极慢，拖长停机时间
- 用
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 300;查超过 5 分钟的事务
更稳妥的做法是：先设好 max: 重启，再通过监控 INFORMATION_SCHEMA.FILES 中 innodb_temporary 表的 TotalSizeBytes 值，观察是否稳定在上限内。
真正治本：别让临时表落到磁盘上
调 innodb_temp_data_file_path 是兜底，不是根治。真正减少 ibtmp1 压力，得从查询层下手：
- 检查
SHOW GLOBAL STATUS LIKE 'Created_tmp_disk_tables';—— 这个值持续上涨，说明大量查询被迫落盘 - 用
EXPLAIN看执行计划，重点找Using temporary; Using filesort，说明排序/分组没走索引 - 增大
tmp_table_size和max_heap_table_size（建议设相同值，如64M），让小结果集留在内存 - 避免
SELECT *+ORDER BY大字段，改用覆盖索引或分页拉取
最易被忽略的一点：ibtmp1 占用的是 datadir 所在分区，不是 tmpdir；很多人查 /tmp 空间充足就放松警惕，其实 /data/mysql 才是雷区。
