大事务导致binlog“假死”是因为其提交时需一次性flush+fsync大量日志，挤占group commit队列、触发binlog_cache溢出至磁盘临时文件，并可能因锁粒度失控加剧阻塞；拆分事务是根本解法，再合理配置binlog_cache_size（如20mb）、binlog_group_commit_sync_delay（10–100微秒）及同步刷盘参数。
大事务提交卡在 Writing to binlog 状态，不是磁盘慢，是组提交没攒上队、缓存太小或锁粒度失控——调参不解决根本问题，得先拆事务、再配参数、最后看锁。
为什么大事务会让 binlog 写入“假死”？
MySQL 的 binlog 写入不是流式输出，而是事务提交时一次性 flush + fsync。一个改 50 万行的事务，binlog_cache_size 默认仅 32KB，早溢出到磁盘临时文件；同时它独占 binlog group commit 队列，其他事务排队等它写完才能提交，SHOW PROCESSLIST 里大量线程卡在 Writing to binlog 就是典型表现。
更隐蔽的问题是：即使你把事务拆小了，如果单条语句本身生成的 binlog event 超过 max_allowed_packet（默认 4MB），也会在写入阶段直接报错：Got a packet bigger than 'max_allowed_packet' bytes。
拆事务必须避开 OFFSET 和无索引 WHERE
用 LIMIT + OFFSET 分页更新，看似简单，实际在高并发写入场景下极易漏数据或重复——因为新插入的行会改变 OFFSET 偏移位置。正确做法是锚定有序字段（主键或时间戳）滚动推进：
- 优先用
WHERE id BETWEEN ? AND ?，每次取固定范围，查出当前批最大id作为下一批起点 - UPDATE/DELETE 必须带
ORDER BY id LIMIT 5000，避免全表扫描触发表锁 - 禁用
WHERE DATE(create_time) = '2024-01-01'这类函数包裹条件——索引失效，锁住整张表 - INSERT INTO SELECT 类操作，必须确保源表有主键或唯一索引，否则从库回放时可能因排序或锁升级变慢数倍
binlog_cache_size 和 group commit 参数怎么设才不翻车？
binlog_cache_size 是会话级缓冲区，不是全局开关。设太小（如保持默认 32KB）会导致频繁落盘临时文件，SHOW STATUS LIKE 'binlog_cache_disk_use' 非零就说明已在拖慢提交；但设太大（如 1GB）又浪费内存且无收益。实操建议：
- 按单事务平均 binlog 体积估算：比如每行变更生成约 200 字节日志，批量处理 10 万行 → 至少预留 20MB → 设为
20971520 -
binlog_group_commit_sync_delay单位是微秒，不是毫秒。设 1000（即 1ms）在多数 OLTP 场景已偏高；从10～100微秒起步，配合多线程压测观察Binlog_group_commit_trigger_delay是否上升 -
binlog_group_commit_sync_no_delay_count建议保持默认0，或设为10～50作保底；设成 1000 会导致低流量时事务无限等待 - 必须同步确认
sync_binlog = 1且innodb_flush_log_at_trx_commit = 1，否则组提交的 fsync 合并逻辑无效
哪些“优化”反而让延迟更难诊断？
有人试图绕开 binlog 瓶颈，去调 innodb_log_buffer_size 或把 innodb_flush_log_at_trx_commit 改成 2 —— 这两类操作对 binlog 文件写入完全无效，只影响 redo log。
还有人关掉 innodb_support_xa 想省开销，结果大事务崩溃后出现 binlog 有记录而 InnoDB 数据丢失，主从直接断连；或者误信 binlog_format = STATEMENT 更省空间，却在从库因函数、临时表执行失败，延迟变成不可控的“静默卡死”。
真正容易被忽略的是锁粒度：即使你用了主键分批，如果目标表缺失唯一索引，UPDATE ... WHERE pk = ? 仍可能升级为 gap lock，锁住一大片空隙，阻塞其他事务，间接拉长 binlog 提交等待链。
