MySQL的READ-COMMITTED隔离级别必须配ROW格式Binlog，因STATEMENT格式无法保证主从一致性，尤其在当前读场景下易导致主从数据逻辑错位；官方已禁止该组合，运行时需确认@@binlog_format='ROW'且@@transaction_isolation='READ-COMMITTED'。
MySQL 的 READ-COMMITTED 隔离级别为什么必须配 ROW 格式 Binlog？
因为 STATEMENT 格式 Binlog 在 READ-COMMITTED 下无法保证主从一致性，尤其是涉及当前读（如 SELECT ... FOR UPDATE）时，从库重放可能读到不同版本的数据。
根本原因是：STATEMENT 只记录 SQL 文本，不记录实际影响的行；而 READ-COMMITTED 下，同一语句在主库和从库执行时，因事务快照时间点不同，可能锁定或更新完全不同的行。
-
READ-COMMITTED+STATEMENT是 MySQL 明确禁止的组合，启动时会报错：ERROR 1786 (HY000): Statement violates GTID consistency: binlog_format = STATEMENT and transaction_isolation = READ-COMMITTED - 即使绕过检查（如关闭
enforce_gtid_consistency），主从数据逻辑错位风险极高，尤其在有UPDATE ... WHERE依赖子查询结果的场景 -
ROW格式 Binlog 记录的是“哪几行被改了”，与隔离级别解耦，能准确还原主库变更
怎么确认当前 Binlog 格式和事务隔离级别是否匹配？
别只看配置文件——运行时值才真实。MySQL 启动后可通过变量动态修改，但组合约束在会话/全局生效时才校验。
- 查当前 Binlog 格式：
SELECT @@binlog_format;—— 必须是'ROW' - 查当前会话隔离级别：
SELECT @@transaction_isolation;—— 常见返回'READ-COMMITTED' - 查全局默认隔离级别：
SELECT @@global.transaction_isolation;—— 如果应用用START TRANSACTION不显式设级别，就依赖这个 - 注意：
@@tx_isolation是旧别名，已弃用，优先用@@transaction_isolation
READ-COMMITTED 下哪些操作仍可能被 ROW Binlog 拖慢？
ROW 格式本身不解决锁竞争，但会放大某些操作的开销，尤其在高并发写场景。
- 大事务批量更新：Binlog 要逐行记录变更，网络传输、磁盘写入、从库解析压力都上升
- 更新含
TEXT/BLOB字段的行：ROW默认记录完整字段值（除非开启binlog_row_image=MINIMAL），日志体积暴增 - 频繁更新主键：每条更新变成 “delete + insert” 两条事件，Binlog 量翻倍，且从库回放延迟更敏感
- 建议搭配：
binlog_row_image=MINIMAL（只记变更前后主键+被改列），并避免在事务里做跨表大更新
应用层没显式设隔离级别，但用了 READ-COMMITTED，Binlog 还安全吗？
不安全——取决于连接初始化时的实际设置。很多 ORM 或连接池会悄悄覆盖默认值。
- Spring Boot 的
spring.jpa.properties.hibernate.connection.isolation设为4（即TRANSACTION_READ_COMMITTED），会强制每个连接设级别 - Druid 连接池若配置了
initConnectionSqls=SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED，也生效 - 最稳妥做法：在 MySQL 配置中设全局默认
transaction_isolation = READ-COMMITTED，再确保binlog_format = ROW，避免依赖客户端行为 - 漏掉这点，上线后某天突然主从不一致，查日志只会看到一堆
UPDATE在从库没生效，根本原因藏在连接初始化里
