mysql主从复制是读写分离的前提，需确保seconds_behind_master≈0且io/sql线程正常；mybatis plus需借助dynamicdatasource或shardingsphere-jdbc实现路由，推荐@ds注解；事务内强制走主库，跨库join和分布式事务需最终一致性方案。

MySQL 主从复制是读写分离的底层前提

没有主从同步，读写分离就是空中楼阁。应用层把读请求发到从库，但数据还没同步过去，查到的就是过期结果。所以必须先确保 SHOW SLAVE STATUS\G 中 Seconds_Behind_Master 稳定为 0 或极低值（比如 1），且 Slave_IO_Running 和 Slave_SQL_Running 都是 Yes。

常见错误现象：Slave_SQL_Running: No，通常是因为主库执行了 DROP TABLE 或 CREATE TEMPORARY TABLE 这类不被从库兼容的操作；或者从库手动改了数据导致主键冲突。

• 主库 binlog_format 必须设为 ROW，MIXED 在某些场景下会丢变更
• 从库建议开启 read_only=1，防止应用误写入（但 root 用户仍可写，需额外限制）
• 避免在从库执行 STOP SLAVE 后长时间不启，容易因 binlog 清理导致同步断裂

MyBatis Plus 多数据源下怎么路由读/写

MyBatis Plus 本身不带读写分离能力，得靠 DynamicDataSource 或 ShardingSphere-JDBC 这类中间件做路由。最轻量的是用 com.baomidou.dynamic.datasource.DynamicRoutingDataSource，它根据方法名前缀或注解决定走哪个数据源。

使用场景：服务里一个 UserService，getUserById 走从库，updateUser 走主库——不能靠 SQL 类型判断（比如 SELECT 就走从库），因为有些业务逻辑里 SELECT ... FOR UPDATE 必须走主库。

• 推荐用 @DS("slave") 注解标在 service 方法上，比正则匹配更可控
• 事务方法内如果嵌套了 @DS("slave")，会被忽略，整个事务强制走主库——这是正确行为，不是 bug
• 注意 DataSource bean 初始化顺序：主数据源必须叫 master，否则 DynamicRoutingDataSource 找不到默认源

ShardingSphere-JDBC 的 readwrite-splitting 配置要点

ShardingSphere-JDBC 是目前最成熟的读写分离嵌入式方案，但配置稍复杂。核心是定义 write-data-source-name 和 read-data-source-names，它不会自动发现从库延迟，得靠 load-balancer-name 控制怎么选从库。

性能影响：默认负载均衡策略是 ROUND_ROBIN，但如果某个从库延迟高，请求分过去就拖慢整体响应。可以换 RANDOM 或自定义实现 SQLHint 强制走指定从库。

• props 下加 sql-show: true 可看实际路由日志，确认读请求是否真发到了从库
• 不要把主库地址也塞进 read-data-source-names，否则读压力会反向打到主库
• 如果用了 HikariCP，每个物理数据源都要单独配连接池，别共用一个 HikariDataSource 实例

应用层直连多数据库时，事务和跨库 JOIN 怎么办

一旦拆成主+从多个物理连接，本地事务（@Transactional）就只对当前数据源生效。如果一个方法里既更新主库又查从库，主库失败回滚了，从库那条查询结果已经返回给前端——这不是一致性问题，而是设计误用。

跨库 JOIN 更麻烦：MySQL 不支持主从库之间直接 JOIN，ShardingSphere 也不支持跨写/读数据源的关联查询。

• 事务边界必须收缩到单数据源内，涉及主从协同的逻辑，用最终一致性 + 补偿任务代替
• 需要“读己写”（比如刚下单立刻查订单列表）的场景，读请求必须走主库，别为了读写分离牺牲正确性
• 报表类需求要 JOIN 多张表，优先考虑把汇总结果定时同步到单独的分析库，而不是现场跨主从拉数据

真正难的从来不是配出读写分离，而是判断哪条查询该走从库、哪条必须走主库——这个决策藏在业务语义里，没法靠工具自动猜准。