必须同步设置tmp_table_size与max_heap_table_size为相同值，因mysql取二者较小值作为内存临时表上限；若仅调大前者而后者仍为默认16mb，超限查询将强制落盘至ibtmp1或/tmp，引发“the table is full”错误及磁盘爆满。
只调 tmp_table_size 基本没用，必须同步设好 max_heap_table_size，否则 MySQL 永远按两者中更小的那个值截断。
为什么改了 tmp_table_size 还报 “The table is full”
MySQL 判断是否能走内存临时表，不是看 tmp_table_size 多大，而是取 tmp_table_size 和 max_heap_table_size 的较小值。常见错误是：配置里写了 tmp_table_size = 512M，但忘了改 max_heap_table_size，它还卡在默认的 16MB（即 16777216 字节）。结果所有超过 16MB 的 GROUP BY 或 ORDER BY 查询，全被强制落盘——如果 @@tmpdir 又在根分区，ibtmp1 或 /tmp 就会一路暴涨到爆满。
- 执行
SELECT @@tmp_table_size, @@max_heap_table_size;确认两者数值是否一致（单位是字节） - 查
SHOW GLOBAL STATUS LIKE 'Created_tmp_disk_tables';，如果这个值每秒涨几十次，基本就是内存阈值被卡死了 - 别信慢日志里 “Using temporary” 就代表问题出在参数上——它也可能是因为 SELECT 里带了
TEXT字段，这种情况下再大的内存也拦不住落盘
怎么安全地设两个参数为相同值
不能只写一行配置，也不能靠 SET GLOBAL 临时改——旧连接不生效，重启后又丢失。必须在配置文件里显式并列写两行，且值完全相等。
- 在
/etc/my.cnf的[mysqld]段里加：tmp_table_size = 268435456 max_heap_table_size = 268435456
（即 256MB，注意不要写256M以外的单位，MB或G会解析失败） - 改完必须重启 mysqld；5.7.20+ 可用
SET PERSIST持久化，但依然要重启才对已有连接生效 - 上线前先算余量：单个连接最多吃掉这个大小的内存，如果
max_connections = 500，256MB × 500 ≈ 128GB，远超物理内存，就得往下压——建议上限 ≤ 总内存的 20%
ibtmp1 已经涨到上百 GB 怎么办
ibtmp1 是 InnoDB 内部临时表空间，无法在线收缩。它不会因为删临时表、杀线程、刷脏页就变小，这是引擎设计决定的。
- 唯一可靠释放方式：重启 MySQL。5.7+ 启动时会自动重建
ibtmp1回初始 12MB - 如果实在不能重启，可临时加限制：在配置里设
innodb_temp_data_file_path = ibtmp1:12M:autoextend:max:2G，防止继续膨胀 - 切勿手动
rm -f ibtmp1——mysqld 启动时找不到文件会直接失败 - 重启前务必确认：没有长事务、没有运行中 DDL、主从延迟为 0
比调参更关键的是查清磁盘到底被谁占了
“/var/tmp 100%” 不等于就是 MySQL 临时表干的。很多线上事故最后发现是备份脚本把 .sql 文件 dump 到 /tmp，或者日志轮转没配 maxsize，撑爆了根分区。
- 先查 MySQL 实际用的路径：
SELECT @@tmpdir;，然后df -h /tmp（或对应路径） - 再用
lsof +D /tmp（替换为上一步结果）看哪些 PID 正在往里面写大文件，过滤掉非 mysqld 的进程 - 检查
SHOW GLOBAL STATUS LIKE 'Created_tmp%';的比值：Created_tmp_disk_tables / Created_tmp_tables > 0.1才说明真是临时表落盘太多
最常被忽略的一点：参数调完、ibtmp1 也重启清空了，但过两天又满了——大概率是某条报表 SQL 每天定时跑，中间结果稳定在 300MB，而你只设了 256MB。这时候与其硬抬内存，不如去改 SQL：加覆盖索引、拆分 GROUP BY、避免 SELECT * 带 TEXT 字段。
