ibtmp1暴涨是配置缺失、旧文件未清理、sql未优化三者叠加所致；仅调innodb_temp_data_file_path无效，必须设innodb_fast_shutdown=0后完整重启才能清理旧文件并生效上限。
ibtmp1暴涨不是“用得多就该涨”，而是配置没生效、旧文件没清理、SQL没优化三者叠加的结果。只改innodb_temp_data_file_path却跳过innodb_fast_shutdown = 0和完整重启，等于给漏油的车换标尺——读数准了，但油还在漏。
为什么改了innodb_temp_data_file_path还是涨到上百 GB
这个参数只在 MySQL 启动时起作用，定义新ibtmp1的初始大小和上限（比如ibtmp1:12M:autoextend:max:5G），对已存在的膨胀文件完全无效。旧ibtmp1哪怕你杀光连接、删光临时表，体积也不会缩小——InnoDB 不支持在线收缩临时表空间。
- Linux 下检查
lsof | grep ibtmp1，确认 mysqld 进程已完全退出，否则文件被占用无法删除 - Windows 下用
tasklist | findstr "mysql"查残留进程，必要时用taskkill /f /t /im mysqld.exe强杀 - 若之前启用了
innodb_fast_shutdown = 2（默认值），重启会跳过清理步骤；必须先设为 0 再关库
MySQL 8.0.16+ 升级后 ibtmp1 疯涨，tmp_table_size 为啥不生效
MySQL 8.0 已彻底移除tmp_table_size参数。如果你从 5.7 升级上来，配置文件里还留着它，mysqld 启动时会静默忽略，SELECT @@tmp_table_size可能返回 0 或直接报错Unknown system variable 'tmp_table_size'。
- 真正起作用的是
max_heap_table_size（控制 MEMORY 表和内存临时表上限）和internal_tmp_mem_storage_engine（默认为TempTable） -
temptable_max_ram是核心新参数，决定 TEMPTABLE 引擎总内存池上限，默认为物理内存的 3%（上限 4 GiB），不支持运行时修改，必须写进配置文件 - 例如：在
/etc/my.cnf中添加temptable_max_ram = 4G（8.0.23+ 支持单位 G，旧版本建议写4294967296）
哪些 SQL 最容易把ibtmp1写爆
不是所有 GROUP BY 都危险，关键看执行计划是否落盘、数据量是否超阈值。一旦临时表超过max_heap_table_size（8.0 起取代了tmp_table_size），就会直接写入ibtmp1。
-
EXPLAIN显示Using temporary+Using filesort，且结果集大 -
GROUP BY字段无索引，或用了函数（如GROUP BY DATE(created_at)） -
DISTINCT多字段 + 含VARCHAR(2000)或TEXT列 -
UNION（非UNION ALL）去重，且关联列无索引支撑
真正管用的操作顺序：先查再调最后清
光改配置不碰 SQL，等于给超载卡车换轮胎却不卸货。必须按顺序做：
- 先查落盘频率：
SHOW GLOBAL STATUS LIKE 'Created_tmp_disk_tables'，数值持续上涨说明问题真实存在 - 再定位高消耗 SQL：
SELECT * FROM performance_schema.events_statements_summary_by_digest ORDER BY SUM_TIMER_WAIT DESC LIMIT 10 - 然后才调参：
SET PERSIST max_heap_table_size = 67108864（需 5.7.20+；低版本必须写配置并重启） - 最后执行：
SET GLOBAL innodb_fast_shutdown = 0→SHUTDOWN→ 删除ibtmp1→ 重启
注意：删除前务必确认无长事务残留，用SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 60检查；Windows 下配置文件保存必须选 ANSI 编码，UTF-8 BOM 会导致 mysqld 启动失败且服务按钮变灰。
