批量DELETE导致binlog暴涨，是因为每行删除在ROW或MIXED格式下均生成独立binlog事件，大事务一次性刷盘形成超大记录，拖慢主从回放；根本解法是拆分为小事务（如每次5000行+显式COMMIT），而非调缓存参数。
为什么批量DELETE会让binlog突然暴涨？
因为每行DELETE都会生成一条ROW格式的binlog事件（即使你用的是MIXED，InnoDB在有索引且条件明确时也倾向走ROW），100万行就对应约100万条事件。更关键的是：这些事件不是“打包写入”，而是随事务提交一次性刷盘——如果单个事务删100万行，binlog文件里就会塞进一个超大事务记录，从库回放时只能串行解析+应用，直接卡死SQL Thread。
控制binlog体积的核心是拆事务，不是调参数
别指望靠binlog_cache_size或max_binlog_cache_size来“缓解”——它们只影响缓存，不改变最终写入量。真正有效的是把大事务切成小事务，让每个事务产生的binlog可控、可预测：
- 显式使用
BEGIN/COMMIT包裹每次删除，例如每次删5000行后提交 - 避免在存储过程中隐式累积事务（比如循环里没手动
COMMIT） - 确认
autocommit=1已关闭，否则每条DELETE都成独立事务，binlog碎片化严重、总IO反而更高 - 慎用
SET sql_log_bin = 0：它虽能跳过binlog，但主从数据立刻失配，且无法用于误删恢复
用主键分段比时间字段更稳，也更利于binlog节奏控制
用WHERE create_time 这种条件批量删，容易因索引选择性差、数据分布不均，导致某次扫描实际删了8万行、下一次只删200行——binlog输出忽大忽小，从库延迟曲线毛刺明显。换成基于自增<code>id分段，节奏就平滑得多：
DELETE FROM orders WHERE id BETWEEN 100001 AND 105000 LIMIT 5000;
这样每次执行都严格控制在5000行内，binlog体积稳定，从库回放压力均匀。注意：LIMIT必须带，否则BETWEEN可能意外命中更多行；还要确保id上有索引，否则全表扫描会拖垮性能并锁更久。
触发器和外键会让binlog雪上加霜
如果表上有AFTER DELETE触发器，每删一行它都执行一次，等于放大了binlog写入倍数（触发器里的INSERT/UPDATE也会各自记binlog）。外键级联删除同理——它本质是隐式多表DML，每张被级联的表操作都会单独记binlog。解决办法很直接：
- 删前用
SHOW CREATE TABLE检查是否有触发器，有则用RENAME TRIGGER t_old TO t_old_disabled临时绕过（MySQL不支持DISABLE TRIGGER） - 确认无级联外键，或提前
ALTER TABLE ... DROP FOREIGN KEY（删完再加回） - 不要依赖
SET foreign_key_checks = 0：它不阻止binlog生成，只跳过约束校验，风险极高
真正难控的从来不是语句怎么写，而是你删的那批数据，是否牵动了其他表、触发器、统计逻辑——这些隐式依赖一旦进入binlog，就再也无法“削峰填谷”。
