mysql主从复制本身不提供读写分离功能，需依赖外部组件或应用层实现；常见方式包括应用层硬编码、中间件代理（如proxysql）和智能驱动（如shardingsphere-jdbc）；需应对从库延迟、强一致读强制走主、主从切换后链路恢复等关键问题。
MySQL 主从复制本身不提供读写分离功能
主从复制只是数据同步机制，INSERT/UPDATE/DELETE 写操作必须发往主库，SELECT 读操作可以发往从库——但这个路由决策不在 MySQL 自带能力范围内。MySQL 官方没有内置读写分离代理或驱动层自动路由，必须靠外部组件或应用层控制。
常见读写分离实现方式及选型要点
实际落地有三类主流路径，各自适用不同阶段和约束：
-
应用层硬编码：在业务代码中显式指定数据源，比如用
masterDataSource和slaveDataSource两个连接池，DAO 层按方法名（如getUserById）或注解（如@ReadOnly）分发。适合小团队、强可控场景，但侵入性强、易出错 -
中间件代理：部署
ProxySQL或MaxScale，配置规则将SELECT转发到从库、其余语句打向主库。需注意：SELECT ... FOR UPDATE必须走主库，否则会报Lock wait timeout exceeded；事务内所有语句默认应落在同一节点，ProxySQL 的transaction_persistent需开启 - 智能驱动（如 ShardingSphere-JDBC）：以 JDBC Driver 形式嵌入应用，通过配置
readwrite-splitting规则实现透明路由。优势是零代理运维，缺点是升级驱动版本可能影响 SQL 兼容性，且对UNION ALL、子查询等复杂语句的解析存在边界 case
从库延迟导致读取脏数据的应对策略
即使读写分离配置正确，从库延迟（Seconds_Behind_Master > 0）仍会让应用读到过期数据。这不是配置问题，而是架构权衡：
- 监控必须覆盖
Seconds_Behind_Master，告警阈值建议设为 5 秒以上（取决于业务容忍度） - 对一致性要求高的读操作（如订单支付后查状态），强制走主库，可用
/*+ FORCE_MASTER */注释（ProxySQL 支持）或应用层直连masterDataSource - 避免依赖从库做“先读后写”逻辑，例如
SELECT count(*) FROM t WHERE status=1后再INSERT，这类场景本质不适合读写分离
主从角色切换后读写分离链路是否自动恢复？
不会自动恢复。当发生主从切换（如 MHA、Orchestrator 故障转移后），原主库变从库、原从库变主库，但 ProxySQL 或应用里的连接池仍按旧地址和角色缓存工作：
- ProxySQL 需配合脚本监听
mysql_servers表变更，或通过mysql_replication_host_groups+monitor_username自动识别新主 - ShardingSphere-JDBC 依赖注册中心（ZooKeeper/Nacos）感知拓扑变化，若未启用
orchestration模块，则需重启应用 - 最稳妥的做法仍是把主从地址抽象为逻辑名（如
mysql-primary、mysql-replica），由服务发现或 DNS 动态解析，而非写死 IP+端口
