READ-COMMITTED 隔离级别强制要求 binlog_format = ROW，因 MVCC 依赖每行最新已提交版本，与 STATEMENT 日志重放逻辑冲突；RR 级别理论上兼容 STATEMENT，但需规避非确定性函数等风险；MIXED 在 RC 下实际等价于 ROW；版本升级可能改变默认行为，需显式配置并校验。
READ-COMMITTED 隔离级别强制要求 binlog_format = ROW
MySQL 在 READ-COMMITTED（RC）隔离级别下，InnoDB 引擎的 MVCC 实现依赖于“每行记录的最新已提交版本”，这与 STATEMENT 格式 binlog 的重放逻辑天然冲突：主库执行的 UPDATE 语句在从库重放时，可能因读取到不同快照而更新错行或漏更新。因此，MySQL 会直接拒绝写入 binlog。
常见错误现象：
ERROR 1665 (HY000): Cannot execute statement: binlogging impossible since the statement is non-deterministic.Cannot execute statement: impossible to write to binary log since BINLOG_FORMAT = STATEMENT and at least one table uses a storage engine limited to row-based logging.
实操建议：
- 若必须用 RC，请确认
binlog_format已设为ROW或MIXED（后者在 RC 下实际也降级为 ROW） - 检查方式：
SELECT @@binlog_format, @@transaction_isolation; - 修改方式：
SET GLOBAL binlog_format = 'ROW';（需 SUPER 权限，且重启后失效；持久化需写入 my.cnf 的[mysqld]段） - 注意：MySQL 5.7.7+ 默认
binlog_format = ROW，但旧配置或容器镜像可能仍为STATEMENT
Repeatable-Read 隔离级别允许 binlog_format = STATEMENT，但有严格前提
REPEATABLE-READ（RR）是 MySQL 传统默认隔离级别，其 MVCC 基于事务启动时的 ReadView，能保证语句级一致性，因此理论上兼容 STATEMENT 格式 binlog。
但实际中仍可能报错，原因包括：
- 使用了非确定性函数（如
NOW()、UUID()、USER()），导致主从执行结果不一致 - 涉及
INSERT ... SELECT或子查询，且被查表无唯一索引，引发主从扫描顺序差异 - MySQL 版本较老（如 5.1–5.6），存在已知 bug（如 Bug #40360），即使 RR + STATEMENT 也会拒绝写 binlog
实操建议：
- 若坚持用
STATEMENT，务必避免非确定性函数；可用SELECT @@sql_mode;检查是否含STRICT_TRANS_TABLES等约束 - 线上环境强烈建议禁用
STATEMENT—— 它在复杂查询、函数、触发器场景下极易导致主从数据漂移 - RR + ROW 是最稳妥组合，虽日志体积增大，但复制精确、调试可逆（
mysqlbinlog --base64-output=DECODE-ROWS -v可读）
binlog_format = MIXED 不是“自动兜底”，它在 RC 下等价于 ROW
MIXED 模式看似灵活，实则策略简单：对“安全”的语句（如简单 UPDATE 带主键 WHERE）用 STATEMENT，其余一律退化为 ROW。但关键点在于——只要事务隔离级别是 READ-COMMITTED 或 READ-UNCOMMITTED，MySQL 会直接跳过判断，全程使用 ROW 格式记录所有 DML。
这意味着：
-
MIXED在 RC 下 ≠ 混合，而是 100% ROW - 切换
MIXED并不能绕过 RC 对 ROW 的硬依赖 - 若误以为
MIXED能缓解 IO 压力，在 RC 场景下会失望——日志量和ROW完全一致
实操建议：
- 不要为“省事”选
MIXED；明确业务需求后再定格式：需要审计/重放 → 用ROW；极简只读从库且语句完全确定 → 才考虑STATEMENT -
MIXED的真实价值在 RR 下：对CREATE TABLE ... SELECT等语句自动切 ROW，其余走 STATEMENT，平衡兼容性与体积
MySQL 版本升级可能让旧配置突然失效
MySQL 5.7 升级到 8.0 或 5.1 升级到 5.7 后，binlog_format 默认值、RC/RR 的 binlog 兼容策略、甚至错误提示文案都可能变化。最典型的是：旧版报错只提“non-deterministic”，新版直接锁定“INNODB is limited to row-logging when transaction isolation level is READ COMMITTED”。
容易踩的坑：
- 沿用旧 my.cnf 中
binlog_format = STATEMENT，升级后 RC 事务全部失败，但应用层只看到连接超时或空异常 - 容器部署时 base image 使用官方 latest，MySQL 小版本升级（如 8.0.33 → 8.0.39）悄悄收紧了 binlog 校验逻辑
- 开发环境用 SQLite 或本地 MySQL 调试，没开 binlog，上线后才暴露问题
实操建议：
- 每次 MySQL 升级前，用
mysqld --verbose --help | grep "binlog-format"查默认值 - 在初始化 SQL 中显式设置：
SET PERSIST binlog_format = 'ROW';（8.0.14+）或写死 my.cnf - 压测阶段必加 binlog 校验：对比主从
SELECT COUNT(*)和关键字段校验和
