mysql主从复制本身不自动实现读写分离，需在应用层或中间件层控制：写操作发主库、读操作分发从库，注意主从延迟、“读己之写”一致性、事务内读写同节点等关键问题。
MySQL 主从复制本身不自动实现读写分离，它只是数据同步机制；读写分离需要在应用层或中间件层主动控制——写操作发给主库，读操作分发到从库。
应用层手动路由（最直接）
在代码中明确指定数据库连接目标。比如用不同数据源配置主库（写）和从库（读），业务逻辑判断操作类型后选择对应连接。
- 增删改（INSERT/UPDATE/delete）必须走主库连接
- 查询（select）优先走从库连接，但需注意“刚写完立刻查”的场景——可能因主从延迟读不到最新数据，此时应强制走主库（即“读己之写”一致性处理）
- 可封装一个简单路由工具类，根据 SQL 类型或注解（如 @Read / @Write）自动选库
使用代理中间件（推荐用于中大型项目）
把读写分离逻辑下沉到独立组件，对应用透明。常见方案有：
- MySQL router：官方轻量代理，支持读写分离和故障转移，配置简单，适合标准主从架构
- proxySQL：功能强大，支持 SQL 解析、读写分离、连接池、自动故障检测与权重调度，可基于用户、SQL 类型、响应时间等精细化分流
- MaxScale：mariadb 官方出品，也兼容 MySQL，提供负载均衡、读写分离、防火墙等功能
部署后，应用只需连接代理地址，由代理按规则转发请求，无需修改业务代码。
ORM 框架集成（开发友好型）
部分框架或插件已内置读写分离能力：
- mybatis 可配合 dynamic-datasource-spring-boot-starter 实现多数据源 + 注解切换
- ShardingSphere-JDBC 是 JDBC 层的分库分表+读写分离框架，以 jar 包形式嵌入应用，支持自动识别读写 SQL 并路由
- spring boot + AbstractRoutingDataSource 可自定义数据源路由策略，灵活但需自行维护一致性逻辑
关键注意事项
读写分离不是一配就灵，几个容易踩坑的点要提前考虑：
- 主从延迟：从库同步存在毫秒到秒级延迟，强一致读必须走主库，不能依赖从库实时性
- 事务内读写混合：一个事务中既有写又有读，全部操作必须落在同一节点（通常是主库），否则会报错或数据异常
- 从库数量与负载均衡：多个从库时，需合理分配读请求，避免单点过载；ProxySQL 等支持按响应时间或连接数动态加权
- 健康检查与自动摘除：从库宕机或延迟过大时，应自动剔除，防止请求失败或拖慢整体性能
读写分离本质是流量调度问题，核心在于让写操作不阻塞读，同时保障必要的一致性边界。技术选型要看团队运维能力、业务一致性要求和系统规模——小项目用应用层控制够用，中大型建议上 ProxySQL 或 ShardingSphere 这类成熟中间件。