事务隔离级别不一致会导致主从数据脱节，因主库与从库transaction_isolation设置不同，使同一事务在主库执行成功、从库回放时产生语义差异，尤其在SELECT ... FOR UPDATE或子查询依赖当前读场景下易漏更新或重复插入。
为什么事务隔离级别不一致会导致主从数据脱节
主库和从库的 transaction_isolation 设置不同，会让同一个事务在主库执行成功、在从库回放时产生语义差异——尤其是涉及 SELECT ... FOR UPDATE 或子查询依赖当前读的场景。比如主库用 REPEATABLE READ，从库误设为 READ COMMITTED，SQL线程执行时可能锁住更少行、跳过本该更新的记录，最终导致从库漏更新或重复插入。
如何快速确认主从隔离级别是否一致
直接比对主从库的运行时配置，不是看 my.cnf 里的静态值（可能未生效）：
- 主库执行：
SELECT @@transaction_isolation; - 从库执行：
SELECT @@transaction_isolation; - 若结果不一致（如主库返回
REPEATABLE-READ，从库返回READ-COMMITTED），就是隐患源头
注意：MySQL 8.0+ 返回值带连字符（REPEATABLE-READ），5.7 是下划线（REPEATABLE_READ），字符串比较时需标准化处理。
修复时不能只改配置，必须配合同步点重置
仅在从库执行 SET GLOBAL transaction_isolation = 'REPEATABLE-READ'; 不足以解决问题——已拉取但尚未执行的中继日志（Relay Log）仍按旧隔离级别解析，错误已埋下。
- 先停复制：
STOP SLAVE; - 确认当前同步位点：
SHOW SLAVE STATUS\G记下Relay_Master_Log_File和Exec_Master_Log_Pos - 修改从库配置文件（如
/etc/my.cnf），在[mysqld]下添加：transaction_isolation = REPEATABLE-READ - 重启从库 MySQL 进程（确保全局变量生效）
- 重新指向原位点启动复制：
CHANGE MASTER TO MASTER_LOG_FILE='xxx', MASTER_LOG_POS=yyy;，再START SLAVE;
跳过这一步直接 START SLAVE，SQL线程会继续用旧上下文执行积压的 Relay Log，脱节依旧。
长期防护：避免隔离级别被会话级覆盖
应用连接池或中间件可能在建连后执行 SET SESSION transaction_isolation = ...，这种会话级设置不会影响复制SQL线程（它走专用线程），但容易掩盖配置问题。真正要防的是DBA或部署脚本误改全局值。
- 上线前加检查项：
SELECT COUNT(*) FROM performance_schema.global_variables WHERE VARIABLE_NAME = 'transaction_isolation' AND VARIABLE_VALUE != 'REPEATABLE-READ'; - 监控告警：对主从库定期采集
@@transaction_isolation值，做字符串 diff - 禁止在从库执行
SET GLOBAL—— 配合read_only = ON+ 复制账号无 SUPER 权限
最隐蔽的坑是：主从都显示 REPEATABLE-READ，但主库用了 binlog_format = STATEMENT，而某些函数（如 NOW()、UUID()）在不同隔离级别下表现不同，导致语句级复制结果错位——所以务必同时检查 binlog_format 和隔离级别是否匹配。
