mysql读写分离下如何保证事务一致性_利用强一致性读配置

事务内读操作必须走主库，因读写分离中间件不感知事务上下文，SELECT...FOR UPDATE等需加锁语句及强一致性读依赖GTID+ROW格式复制，应用层须控制连接路由与事务边界。事务内读操作必须走主库，read_only 不能绕过MySQL 读写分离下，事务中的 SELECT 默认可能被路由到从库，导致读到旧数据或事务间不一致。这不是中间件或代理的 bug，而是多数读写分离方案（如 ProxySQL、ShardingSphere、甚至应用层 DataSource 路由）的默认行为------它们只看 SQL 类型，不感知事务上下文。真正起作用的是 MySQL 自身的 innodb_read_only 和会话级 read_only 配置，但注意：read_only=ON 在从库上是强制的，而在主库上设为 ON 会直接拒绝写入，所以它不能用来"标记事务该走哪"。关键在客户端控制：开启事务前，显式执行 SET SESSION innodb_read_only = OFF（仅对当前连接有效，且仅当主库未设全局 read_only=ON 时才允许）更可靠的做法：所有事务一律使用主库连接池，不在事务中切换数据源如果用 MyBatis + Druid，确保 @Transactional 方法绑定的 DataSource 是主库，而非逻辑路由后的抽象源SELECT ... FOR UPDATE 和 SELECT ... LOCK IN SHARE MODE 必须命中主库这类语句本质是写操作前置，需要加行锁、更新事务视图（read view），若落到从库会报错或静默失败。常见错误现象：Lock wait timeout exceeded; try restarting transaction 或直接返回空结果，但无明确提示。原因在于从库的 relay_log 回放有延迟，且不支持加写锁。即使你配置了 slave_parallel_type=LOGICAL_CLOCK，也不能改变这个限制。检查中间件是否识别 FOR UPDATE 并自动切主------不是所有代理都支持，ProxySQL 需要自定义 mysql_query_rules 规则匹配正则 SELECT.*FOR UPDATESpring Boot 中，避免在 @Transactional(readOnly = true) 方法里混用 FOR UPDATE，这会导致事务实际以只读开启，后续加锁失败若用 xa_transaction 或跨库事务，FOR UPDATE 必须全部落在同一节点，否则两阶段提交会卡在 prepare 阶段强一致性读配置：transaction_isolation = REPEATABLE-READ 不够，得靠 binlog_format = ROW + GTID很多人以为调高隔离级别就能解决一致性，其实不然。REPEATABLE-READ 只保证单库事务内可重复读，无法约束主从之间数据新鲜度。真正影响"强一致性读"的是复制机制本身。 VWO 一个A/B测试工具