RC隔离级别下STATEMENT格式binlog会直接报错，因MVCC依赖每行最新已提交版本，而STATEMENT重放无快照，导致主从执行结果不一致，MySQL内核拒绝写入并抛出ERROR 1665。
RC隔离级别下STATEMENT格式会直接报错
MySQL在READ-COMMITTED隔离级别下，InnoDB的MVCC机制依赖“每行最新已提交版本”来判断可见性。而STATEMENT格式binlog重放时，是从头执行SQL语句，不带原始事务快照——从库SQL线程读到的行版本可能和主库当时不同，导致UPDATE改错行、DELETE漏删或误删。MySQL内核检测到这种不可靠性后，会直接拒绝写入binlog，抛出ERROR 1665 (HY000): Cannot execute statement: binlogging impossible since the statement is non-deterministic.。
RC + STATEMENT组合存在逻辑断层
主库在RC下执行UPDATE t SET x = 1 WHERE y > 10时，实际影响的是“当前已提交且满足条件的行集合”。但从库重放该语句时，若中间有其他事务提交了新行，或某些行被其他事务回滚又重试，结果集就可能扩大或缩小。这不是执行错误，而是语义层面的不可对齐。
-
SELECT @@transaction_isolation和SELECT @@binlog_format必须同时检查，不能只看其中一个 - 即使显式设了
SET SESSION transaction_isolation = 'READ-COMMITTED'，只要binlog_format仍是STATEMENT，后续DML仍会触发报错 -
MIXED模式在RC下实际自动降级为ROW，但行为不透明，不建议依赖
切到ROW后从库报1032错误不是格式问题，是旧账暴露
Error_code: 1032（Can't find record in table）常在切换到ROW后突然出现，但这不是ROW的缺陷，而是它把早已存在的主从数据不一致“显性化”了。STATEMENT模式下，哪怕UPDATE找不到匹配行也可能静默成功；ROW模式则严格要求“行必须存在才能更新”。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 常见诱因：主库还在STATEMENT模式时写了含
NOW()的记录，从库执行后时间偏移，后续ROW日志按原时间戳找行失败 - 另一个坑：
SET GLOBAL binlog_format = 'ROW'只影响新连接，老连接仍在写STATEMENT日志，造成混合binlog，从库解析时容易卡住 - 无主键表在ROW下复制效率极低，因为MySQL需全表扫描匹配WHERE条件，延迟会陡增
确认和持久化ROW格式的关键动作
别信默认值，也别只在会话里临时设置。生产环境必须做两件事：
- 运行
SELECT @@binlog_format确认当前值是'ROW'，不是'STATEMENT'或空字符串 - 在
my.cnf的[mysqld]段落中写死binlog_format = ROW，否则重启后回退 - 如果用容器部署，检查基础镜像是否覆盖了配置——很多MySQL 5.7+官方镜像仍默认STATEMENT
真正麻烦的从来不是切换动作本身，而是切换前主从之间已经积累的、被STATEMENT模式掩盖的数据偏差。这些偏差在ROW模式下不会自动修复，得靠pt-table-checksum一类工具主动发现。
