MySQL 5.7 中 binlog_cache_size 过小不会直接导致 ibtmp1 或 /tmp 爆满，它仅引发 binlog 磁盘写入增多；真正撑爆临时空间的是大排序、JOIN 落盘、长事务或 tmpfs 分区过小，需优先监控 ibtmp1 大小、@@tmpdir 实际路径及磁盘使用率。
MySQL 5.7 不会因 “binlog 缓存不足” 直接导致临时文件写满 —— 这是个常见误解。真正触发 ibtmp1 或 /tmp 爆满的，是事务过大、排序/JOIN 落盘、或 binlog_cache_size 设置过小迫使 binlog 写入磁盘，但根本瓶颈在临时表空间或系统临时目录，而非 binlog cache 本身。
为什么 binlog_cache_size 小 ≠ 临时文件爆炸
binlog cache 是每个线程独占的内存缓冲区，只用于暂存**当前事务的 binlog 事件**。它超限时会把这部分日志刷到磁盘上的 binlog 文件（如 mysql-bin.000123），而不是写进 ibtmp1 或 /tmp。所以：
• binlog_cache_size 太小 → 更多磁盘 I/O 写 binlog，但不产生临时表文件
• 真正撑爆 ibtmp1 的是大排序、JSON 函数、CREATE TABLE AS SELECT、未提交长事务
• 真正撑爆 /tmp 的是 GROUP BY / ORDER BY 落盘、ALTER TABLE 重建、或 tmpfs 分区太小
排查时优先盯死这三个地方
别在 binlog_cache_size 上浪费时间，先确认真实瓶颈：
- 查
ibtmp1实际大小：ls -lh /var/lib/mysql/ibtmp1—— 若 >1GB，基本就是它在吃空间 - 查 MySQL 正在用哪个临时目录：
SELECT @@tmpdir, @@innodb_tmpdir;—— 注意 CentOS 默认/tmp是 tmpfs，大小常只有 1–2GB - 查磁盘挂载点真实使用率：
df -h /var/lib/mysql /tmp—— 如果/tmp显示 100% 但du -sh /tmp/*总和很小，说明有“已删未释放”的幽灵文件，用lsof +L1找进程
SHOW PROCESSLIST 里看到 Copying to tmp table 就该动手了
这个状态不是“正在拷”，而是“卡在写临时文件”——内核拒绝写入，MySQL 在轮询重试。此时：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 立刻执行
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 60;—— 若有结果，说明长事务正霸占ibtmp1空间 - 检查慢查询日志里是否有三表无条件 JOIN、全表 ORDER BY、或
JSON_EXTRACT大字段 —— 这些是ibtmp1暴涨元凶 - 若 MySQL ≥ 5.7.30，可立即运行
ALTER TABLESPACE innodb_temp_tablespaces ENCRYPTION='N';强制收缩（注意：需无活跃长事务） - 若版本低于 5.7.30，只能等业务低峰期重启 MySQL ——
ibtmp1会在启动时重建为初始 12MB
别碰 binlog_cache_size，但要调这两个参数防复发
binlog_cache_size 默认 32KB，对绝大多数事务够用；盲目调大反而浪费内存。真正该调的是：
-
tmp_table_size和max_heap_table_size：控制内存临时表上限，设为 64M～256M（需两者一致），减少落盘频率 -
innodb_temp_data_file_path = ibtmp1:12M:autoextend:max:2G：在my.cnf中硬限ibtmp1最大尺寸，避免失控增长 - 确认
tmpdir指向真实磁盘分区（如/data/tmp），而非内存/tmp—— 尤其 RDS 用户需检查参数组是否被覆盖
最易被忽略的一点：ibtmp1 不会随表删除自动收缩，哪怕你刚 DROP 了几个上百 GB 的表，它体积纹丝不动。监控必须单独盯 ibtmp1 文件大小，而不是只看 data_length。
