ibtmp1 会无限增长是因为 mysql 5.7+ 默认使用独立临时表空间且不自动收缩，需通过 innodb_temp_data_file_path 的 max: 参数硬性限制大小，否则可能占满磁盘导致启动失败。
ibtmp1 文件为什么会无限增长
MySQL 5.7+ 默认用独立的 ibtmp1 存临时表数据，不是放在系统表空间里。它不自动收缩，哪怕你删光了所有临时表，文件体积也不会变小——这是设计如此，不是 bug。
常见错误现象：ibtmp1 占满磁盘、监控报警、mysqld 启动失败（报 Cannot initialize temporary tablespace）。
- 只在事务中显式建临时表（
CREATE TEMPORARY TABLE）或隐式用到大排序/哈希（如ORDER BY、GROUP BY、JOIN缓冲不足时）才会写入ibtmp1 -
innodb_temp_data_file_path配置决定它的位置和初始大小，但默认没设上限 - 重启 MySQL 会清空
ibtmp1（重建），所以「重启能救急」但不能当常态方案
如何限制 ibtmp1 最大大小
靠 innodb_temp_data_file_path 的 max: 参数硬限，不是靠其他开关。不配这个，就等于没限制。
示例配置（加在 my.cnf 的 [mysqld] 下）：
innodb_temp_data_file_path = ibtmp1:12M:autoextend:max:2G说明：
-
ibtmp1:12M：初始大小 12MB（可改，但别太小，否则频繁扩展影响性能） -
autoextend：允许增长（必须带，否则启动失败） -
max:2G：绝对上限，达到后 MySQL 拒绝新临时表操作，报错Operating system Error number 28 in a file operation. Error number 28 means 'No space left on device' - 路径可以是绝对路径，比如
/data/mysql/ibtmp1:12M:autoextend:max:4G，方便隔离 I/O 或挂载独立磁盘
配置后为什么还是涨破了限制
两个最常被忽略的点：配置没生效、或根本没走 InnoDB 临时表路径。
- 确认配置已加载：连上 MySQL 执行
select @@innodb_temp_data_file_path;，输出必须含max:，否则说明配置写错位置或 mysqld 没重读 - 检查是否用了 MyISAM 临时表：如果 SQL 中有
CREATE TEMPORARY TABLE ... ENGINE=MyISAM，那数据进的是tmpdir（由tmpdir变量控制），跟ibtmp1无关 - 大事务中反复创建/删除临时表，可能触发多次 autoextend，但只要总大小没超
max就不会报错；真正爆限是某次扩展申请超过剩余空间时才触发 - 注意磁盘预留空间：即使
max:2G，若磁盘只剩 1.5G，扩展失败照样报错
要不要把 ibtmp1 放到 SSD 或独立磁盘
要看负载类型。临时表 I/O 是典型的高随机写场景，尤其 OLAP 查询多时，ibtmp1 容易成为瓶颈。
- 如果业务常跑大报表、etl、导出类 SQL，建议用高速本地 SSD 或 NVMe 单独挂载目录，再通过
innodb_temp_data_file_path指向它 - 不要和
datadir共用同一块慢盘（比如机械盘），否则排序/聚合明显变慢 - 不建议 NFS 或网络存储——InnoDB 临时表空间要求 POSIX fallocate 支持，多数网络文件系统不满足，启动直接失败
- 线上改路径需停机：因为
ibtmp1在运行时无法移动，只能停库 → 修改配置 → 启动（此时重建空文件）
MySQL 的 ibtmp1 不是“能用就行”的配置项，它的大小、位置、上限都会直接影响查询稳定性和磁盘安全。最容易被跳过的其实是验证步骤：改完配置不查 @@innodb_temp_data_file_path，也不压测极限场景，等半夜磁盘告警才反应过来。