报错是这么冒出来的。MySQL 8.0 的主库上，binlog 一小时涨二十 G，磁盘只剩几十 G，可业务只是批量更新几张表，从库延迟也正常，看着不像有大批量导入。
中间走过弯路，把「批量更新放在一个事务里，几十万行一起提交，单个事务就把日志顶起来」当成主因，改完现象没变。
原因不止一个，得分开看。使用的是行格式日志，每一行变更都把前后两个镜像完整记下来。另一种情况是binlog_row_image 是 FULL，几 M 的文本字段即使只改一个状态也要整段写进去。
少数情况下是日志保留时间没设或者设得很长，文件只增不删。
第一件事是确认日志格式与行镜像策略
mysql -e 'show variables like "binlog_format"; show variables like "binlog_row_image";'再往下看增量集中在哪些时间点
ls -lh /var/lib/mysql/binlog.* | tail -5随后改成只记变更列，压缩体积
mysql -e 'set global binlog_row_image=MINIMAL;'等前面都确认过，再确认保留时长并清理过期文件
mysql -e 'show variables like "binlog_expire_logs_seconds"; purge binary logs before now() - interval 3 day;'怎么算真的好了，看的是同一批现象。同样业务量下 binlog 每小时增量降到五 G 以下，从库延迟没有恶化，df 显示数据盘可用空间稳定回升。
这里还有个坑。最小镜像会影响某些依赖整行数据的同步工具，改之前确认下游有没有按旧值做判断的逻辑。如果同一现象隔几天又出现，说明根因没找到，别当偶发处理。