为何RDS MySQL 8.0.28中Repeatable Read下Binlog暴增，Read Committed下缩减？

1. 间隙锁触发Binlog格式降级 #

当隔离级别为Repeatable Read（RR）时，InnoDB依赖间隙锁（Gap Lock）和Next-Key Lock机制防止幻读，这会让部分UPDATE/DELETE语句的实际锁定范围超出语句语义。

• 你的Binlog格式为Mixed，该格式默认优先用语句级（Statement）记录，但当语句涉及间隙锁、或操作非唯一索引的范围查询时，MySQL会自动切换为行级（Row）Binlog以保证主从数据一致性。行级Binlog会逐条记录每行的修改细节，体积远大于语句级记录。
• 切换到Read Committed（RC）隔离级别后，InnoDB默认关闭间隙锁（仅外键和唯一索引场景保留），同时开启半一致性读（semi-consistent read），绝大多数语句可保持语句级Binlog记录，仅少数特殊场景才会触发行级记录，Binlog体积自然大幅缩减。

2. MySQL 8.0对RR隔离级别的行为强化 #

从5.7升级到8.0.28后，RR隔离级别的幻读防护逻辑更严格，间隙锁的触发场景比5.7更多；同时8.0对行级Binlog的记录格式做了调整，单条行记录的体积相比5.7有所增加，双重因素导致RR下Binlog体积暴涨。
而RC隔离级别在8.0中优化更成熟，半一致性读的逻辑进一步减少了行级Binlog的触发概率，这也是切换后体积骤降的原因之一。

3. Multi-AZ RDS的同步放大效应 #

启用Multi-AZ的RDS实例需要将Binlog同步到备节点，RR下大量的行级Binlog会直接增加同步的数据量；同时RDS在Multi-AZ模式下为保证主备一致性，对行级Binlog的记录会更完整，进一步放大了RR和RC之间的Binlog体积差异。

验证建议 #

• 执行SHOW VARIABLES LIKE 'binlog_format';确认Binlog格式的实际生效状态；
• 用mysqlbinlog工具解析部分Binlog文件，对比RR和RC下的记录格式（语句级/行级），直接验证体积差异的来源；
• 查看慢查询日志，排查RR下是否存在大量触发间隙锁的范围更新/删除语句，这类语句是Binlog切换成行级的核心诱因。

内容的提问来源于stack exchange，提问作者Rahul G