row格式下delete语句因记录每行完整前镜像导致binlog体积暴增；大事务未分批会阻塞binlog滚动切片，且回滚后前镜像仍残留占用空间。
DELETE语句在ROW格式下会记录每一行的完整前镜像
MySQL的binlog日志体积暴增，往往不是因为DELETE语句本身，而是它在binlog_format=ROW模式下触发的“行级变更快照”机制。每删除一行，binlog都会记录该行**删除前的完整数据（即前镜像）**，包括所有字段值——哪怕表有20个VARCHAR(500)字段，这一行就可能占几KB。10万行删除，就是10万份这样的快照。
常见错误现象：mysql-bin.000012突然暴涨到800MB，而执行的DELETE FROM orders WHERE status = 'cancelled'只删了不到10万行；用mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.000012 | head -n 50一看，全是### DELETE FROM `db`.`orders`加十几行### @1=...字段赋值。
- STATEMENT格式下，这条DELETE只记一条SQL文本，体积几乎不变
- ROW格式下，它等价于“对每一行执行一次带全字段的DELETE事件”
- MIXED格式不保险：只要语句含
UUID()、NOW()或触发器，MySQL仍会自动降级为ROW模式写入
大事务未分批导致binlog无法滚动切片
binlog文件切换依赖两个条件：达到max_binlog_size（默认1GB）或事务提交。但一个未提交的大DELETE事务，哪怕只删1行，也会让当前binlog文件一直被独占——直到事务结束才可能触发新文件生成。更糟的是，如果这个事务中途失败回滚，binlog里已写入的前镜像也不会被清理，白白占用空间。
使用场景：运维同学想清空历史日志表，直接跑BEGIN; DELETE FROM log_2024 WHERE created_at ，结果卡住30分钟，<code>SHOW PROCESSLIST显示Query状态，而SHOW BINARY LOGS发现mysql-bin.000015涨到1.2GB且不再增长。
- 解决办法不是调大
max_binlog_size，而是拆成每次1000行的循环：用DELETE FROM log_2024 WHERE created_at + 重试逻辑 - 务必在每次
DELETE后显式COMMIT，否则binlog无法释放当前文件句柄 - 避免在从库上执行大DELETE：ROW格式下从库重放时同样要解析并应用全部前镜像，IO压力翻倍
WHERE条件未命中索引导致全表扫描+全行记录
即使binlog_format是ROW，真正决定“记多少行”的关键，是DELETE实际扫描并判断了多少行。如果WHERE条件没走索引，MySQL必须读取整张表逐行比对，每行匹配成功就记一条前镜像——哪怕最终只删了100行，也可能因扫描100万行而产生100万条binlog事件。
典型错误：DELETE FROM users WHERE phone LIKE '%138%'，phone字段无索引；EXPLAIN显示type: ALL；SHOW ENGINE INNODB STATUS里看到Rows examined: 2345678。
- 先用
EXPLAIN确认DELETE是否走了索引，没走就加索引或改写条件 - 避免在WHERE中用函数或通配符前缀（如
UPPER(name)、LIKE '%abc'），它们会让索引失效 - 对大表做DELETE前，用
SELECT COUNT(*)预估影响行数，别靠感觉
sync_binlog=0时系统缓存延迟刷盘放大感知体积
当sync_binlog=0（默认值），binlog只write到OS page cache，不fsync到磁盘。这时你看到ls -lh下mysql-bin.000016瞬间涨到500MB，其实是内核缓存尚未落盘——但SHOW BINARY LOGS和mysqlbinlog仍能读到这些“未持久化”的内容，造成“日志爆炸”的错觉。一旦机器宕机，这部分日志就丢了；但若刚好撑到下次fsync，又会一次性刷满磁盘。
- 线上环境建议设为
sync_binlog=1，确保事务提交即落盘，避免缓存抖动干扰容量判断 - 不要仅凭
du -sh mysql-bin.*估算磁盘压力，要用mysqladmin ext -r -i 1 | grep binlog看实时写入速率 - 监控项应关注
Binlog_cache_use和Binlog_cache_disk_use：后者非0说明内存缓存溢出，开始用临时文件，性能已受损
实际处理大DELETE时，最易被忽略的是混合模式下的隐式降级——你以为开了MIXED就安全，但只要语句里出现SLEEP(1)或调用自定义函数，MySQL就会静默切到ROW格式，且不报任何警告。上线前务必用mysqlbinlog抽样验证真实写入格式。
