直接结论：溢出报错 ERROR 1197 不是调大 max_binlog_cache_size 就能解决的，它只是熔断开关；真正要动的是 binlog_cache_size 和事务结构本身——前者默认仅32KB/128KB，超限即触发串行磁盘写入阻塞 COMMIT，后者需按主键分批、保证幂等、避免锁放大，才能根治 binlog 积压。
直接结论：溢出报错 ERROR 1197 (HY000) 不是调大 max_binlog_cache_size 就能解决的，它只是熔断开关；真正要动的是 binlog_cache_size 和事务结构本身。
为什么 max_binlog_cache_size 调大反而危险？
max_binlog_cache_size 不参与性能优化，只起“硬限制”作用——超了就直接报错 ERROR 1197。它和缓存效率无关，也不影响刷盘行为。
- 默认值在 MySQL 5.7 是 4GB，8.0 是 16MB，但很多云厂商（如阿里云 RDS）会锁死该参数，
SET GLOBAL无效 - 设得过大（比如 2GB），单个事务真把缓存撑满，会吃光内存、拖垮整个实例，尤其连接数多时
- 它和
max_allowed_packet冲突：即使缓存够用，单条语句生成的 binlog event 超过后者，仍会报Got a packet bigger than 'max_allowed_packet' bytes
怎么查是不是 binlog_cache_size 太小？
这才是实际卡住提交、触发磁盘临时文件写入的元凶。每个连接独享一份缓存，默认仅 32KB（5.7）或 128KB（8.0），对批量操作完全不够。
- 查当前值：
SHOW VARIABLES LIKE 'binlog_cache_size'; - 看是否频繁落盘：
SHOW STATUS LIKE 'binlog_cache%';—— 如果binlog_cache_disk_use接近或等于binlog_cache_use，说明几乎每个事务都在刷磁盘 - 临时生效：
SET SESSION binlog_cache_size = 4194304;（4MB）；全局生效需改配置文件或用SET PERSIST（MySQL 8.0+） - 别盲目设成 1GB：按单事务平均 binlog 体积估算，比如 10 万行 × 200 字节 ≈ 20MB，设为
20971520更稳妥
拆分事务比调参更可靠，但怎么拆才不丢不重？
调参只是放宽限制，拆分是从源头切断风险链。关键不是“分多少批”，而是保证每批语义正确、可重试、不依赖隐式状态。
- 切分依据必须稳定：用自增主键或带索引的时间戳字段，例如
WHERE id BETWEEN ? AND ?或WHERE create_time >= ? AND create_time - 避免
LIMIT OFFSET：删除/更新过程中数据可能被并发修改，OFFSET 分页会漏或重复；改用游标式：WHERE id > last_id ORDER BY id LIMIT 1000 - 每次提交后建议
SLEEP(0.1)，缓解主库压力，也降低从库 SQL 线程堆积风险 - 禁用
REPLACE INTO、AUTO_INCREMENT隐式变更等破坏分片连续性的操作
容易被忽略的锁和日志格式陷阱
即使缓存调大、事务拆小，如果锁范围失控或 binlog 格式不当，照样卡住复制链路。
-
binlog_format必须是ROW（STATEMENT 模式下拆分无效，函数/临时表仍被当单条语句重放） - 全表扫描更新（如
WHERE unindexed_col = ?）会升级为表锁，阻塞所有 DML；非唯一索引条件会加 gap lock，锁范围远超实际行 - 确保 WHERE 条件命中唯一索引（如主键等值），配合
SELECT ... FOR UPDATE显式加锁可控制范围，但别滥用 -
innodb_support_xa必须为ON：关掉它可能导致 binlog 与 InnoDB 数据不一致，主从同步中断
真正卡点从来不在参数数字本身，而在于事务是否具备幂等性、切分逻辑是否规避了并发干扰、以及锁是否被意外放大。监控 binlog_cache_disk_use 和 information_schema.INNODB_TRX 中的 trx_rows_modified，比反复调参更能定位根因。
