先确认磁盘告警是否真由binlog引起：通过du -sh检查各类日志大小，结合SHOW VARIABLES LIKE 'log_bin'、SHOW BINARY LOGS及SHOW STATUS LIKE 'Binlog_cache%'判断；再查general_log误开、缓存溢出、大事务源头和主从安全清理策略。
直接看 SHOW BINARY LOGS 和 SHOW STATUS LIKE 'Binlog_cache%'，再结合 du -sh /var/lib/mysql/mysql-bin.* 确认是否真在疯涨——很多“binlog暴增”其实是 slow-query.log 或 general_log 在背锅。
先确认是不是 binlog 本身在涨
磁盘告警 ≠ binlog 问题。2026 年 4 月就有案例：slow_query_log 单独涨到 397GB。必须先定位真实元凶：
- 执行
du -sh /var/lib/mysql/*.log /var/log/mysql/*.log，重点关注mysql-bin.*、slow-query.log、error.log - 运行
SHOW VARIABLES LIKE 'log_bin'，返回ON才算 binlog 开启 - 执行
SHOW BINARY LOGS，看总数和总大小；单个文件超 1GB 且数量持续增加，才基本锁定为 binlog 问题 - 检查是否误开
general_log：SHOW VARIABLES LIKE 'general_log'—— 它记录每条 SQL，不用时务必关掉
查缓存溢出：Binlog_cache_disk_use 是关键指标
大事务导致 binlog 文件暴增，往往不是因为数据量大，而是 binlog_cache_size 太小被迫刷盘，引发串行阻塞。这不是配置问题，是事务行为问题：
- 执行
SHOW STATUS LIKE 'Binlog_cache%'，重点对比Binlog_cache_disk_use和Binlog_cache_use - 若比值 > 5%，说明大量事务已落磁盘临时文件，后续
COMMIT会排队 - 错误日志里搜
ERROR 1197或Failed to write to binlog cache，这是最硬的证据 -
binlog_cache_size是每个连接独占内存（5.7 默认 32KB，8.0 默认 128KB），盲目设成 64MB 可能让 100 个空闲连接吃掉 6.4GB 内存
定位高产 binlog 的事务源头
别调参，先找谁在疯狂写 event。ROW 格式下一条 UPDATE ... WHERE id BETWEEN 1 AND 1000000 可能生成百万级 event，缓存再大也扛不住：
- 查当前格式：
SHOW VARIABLES LIKE 'binlog_format'；非必要场景建议切MIXED（自动降级为 STATEMENT） - 用 SQL 找修改行数最多的事务：
SELECT trx_id, trx_started, trx_rows_modified FROM information_schema.INNODB_TRX ORDER BY trx_rows_modified DESC LIMIT 5 - 关联
performance_schema.events_statements_current查原始 SQL，确认是否是批量更新、误操作或未分页的同步任务 - 开启慢日志抓长事务：
SET GLOBAL long_query_time = 0.1+SET GLOBAL log_slow_admin_statements = ON，重点盯COMMIT耗时异常的线程
主从环境下 PURGE 前必须核对位置
直接 rm mysql-bin.000042 会断主从，从库报错 Got fatal error 1236。安全清理不是删得快，是删得准：
- 主库执行
SHOW MASTER STATUS，记下File字段（如mysql-bin.000123） - 逐台登录从库，执行
SHOW SLAVE STATUS\G，看Relay_Master_Log_File和Exec_Master_Log_Pos - 找出所有从库中
Relay_Master_Log_File序号最小的那个（比如mysql-bin.000098），这就是安全边界——你最多只能PURGE BINARY LOGS TO 'mysql-bin.000099' - 执行
PURGE BINARY LOGS TO 'mysql-bin.000099'或PURGE BINARY LOGS BEFORE '2026-08-06 00:00:00'（注意时间格式必须是Y-m-d H:i:s）
最容易被忽略的是：MySQL 8.0+ 必须用 binlog_expire_logs_seconds，expire_logs_days 已废弃，设了反而可能冲突报错；而 max_binlog_size 过大（如 2GB）会导致单个 binlog 文件解析失败或磁盘打满——这些参数不联动，得一个个验。
