调大tmp_table_size反而让磁盘更快写满，是因为MySQL内存临时表上限取二者较小值，若仅调大tmp_table_size而max_heap_table_size仍为默认16MB，则超16MB即强制落盘至无上限的ibtmp1或共用根分区的/tmp，导致磁盘迅速写满。
为什么调大 tmp_table_size 反而让磁盘更快写满
因为 MySQL 实际内存临时表上限取 tmp_table_size 和 max_heap_table_size 的较小值。你设了 tmp_table_size = 512M，但 max_heap_table_size 还是默认的 16MB，那所有临时表超过 16MB 就强制落盘——不是“不够大”，而是“被悄悄截断”。
更糟的是，落盘目标 ibtmp1 默认无上限，/tmp 又常和根分区共用，一写满就卡死 mysqld。
- 查当前真实生效值：
SELECT @@tmp_table_size, @@max_heap_table_size;，确认两者是否相等 - 别只改一个：必须在
my.cnf的[mysqld]段里显式写两行，例如：tmp_table_size = 256M和max_heap_table_size = 256M - 重启后验证：仅
SET GLOBAL不持久，5.7.20+ 才支持SET PERSIST，否则重启即失效 - 别超物理内存 20%：32GB 机器设到 6GB 是危险线，高并发下每个连接都可能独占一份该内存
EXPLAIN 显示 Using temporary 但参数已调大，为什么还落盘
内存参数只是门槛，SQL 写法才是触发器。哪怕设成 1G，只要满足以下任一条件，MySQL 就会跳过 MEMORY 引擎、直接建磁盘临时表：
- 查询含
BLOB/TEXT字段（MEMORY 引擎不支持） -
ORDER BY或GROUP BY用了函数或表达式，如UPPER(name)、JSON_EXTRACT(data, '$.id') - 排序字段类型不匹配（比如
VARCHAR列和INT常量比较） - 显式指定
ENGINE=MyISAM或ENGINE=InnoDB创建临时表（少见但存在）
这类语句无法靠调参解决，必须重写或加索引。例如把 GROUP BY UPPER(name) 改为先建函数索引，或提前在应用层处理大小写。
Created_tmp_disk_tables 突增，但 df -h 显示磁盘没满
说明问题不在空间耗尽，而在 I/O 饱和或路径争抢。临时表写入频繁时，即使挂 SSD，lsof +D /var/tmp 也可能显示大量小文件反复创建销毁，拖垮 IOPS。
- 先确认 MySQL 实际用的路径：
SELECT @@tmpdir;，再df -h查对应挂载点 - 用
lsof +D /path/to/tmpdir看是不是其他进程（如日志轮转、备份脚本）也在往同一目录写大文件 - 检查权限：
ls -ld $(SELECT @@tmpdir)，确保mysql用户有读写权限 - 如果
ibtmp1已涨到上百 GB，唯一释放方式是重启 MySQL（5.7+ 启动时自动重建为初始 12M）
事务中断报错 ERROR 1114 (HY000): The table 'sql_xxx' is full
这不是磁盘满，而是临时表空间申请失败的典型信号。它往往发生在长事务中，且伴随 SHOW PROCESSLIST 出现大量 Copy to tmp table 状态。
- 立即查：
SHOW GLOBAL STATUS LIKE 'Created_tmp_disk_tables';，比对Created_tmp_tables，比值超 10% 就说明已失控 - 别急着 kill 进程：先确认该会话是否持有未提交事务，否则 kill 会触发回滚，反而加重磁盘压力
- 紧急扩容无效时，优先降级：用
ALTER TABLE ... REMOVE PARTITIONING处理超限分区表（避免 open_files_limit 耗尽），再砍掉低效GROUP BY子查询 - 根本解法是拆分逻辑：把单条报表 SQL 拆成多步中间结果落地，而不是硬扛 500MB 临时表
真正卡住人的从来不是参数数字，而是 tmp_table_size 和 max_heap_table_size 的隐式取小逻辑，以及 SQL 里那些看似无害的函数表达式——它们绕过所有内存配置，直奔磁盘。
