MySQL读写分离需在应用层或中间件层实现：应用层通过多数据源+注解动态路由，强一致性读必须走主库；中间件如ProxySQL可自动解析SQL并智能路由，支持延迟阈值切换；须重视从库延迟、健康检查与负载均衡。
在 MySQL 主从架构中实现读写分离，核心是把写操作（INSERT/UPDATE/DELETE）发往主库，读操作（SELECT）尽量分发到从库，从而降低主库压力、提升整体吞吐能力。这不是 MySQL 自带的功能，需在应用层或中间件层控制流量走向。
应用层手动路由：最直接也最可控
开发时明确区分读写 SQL，在代码中指定连接目标。例如使用不同数据源配置：
- 写操作统一走 masterDataSource（指向主库）
- 读操作优先走 slaveDataSource（可配置多个从库，加权轮询或随机选取）
- 强一致性读（如刚写完立刻查）必须回主库，避免从库延迟导致数据不一致
适合中小规模、技术栈较可控的项目。Spring Boot 中可用 AbstractRoutingDataSource 动态切换数据源，配合注解（如 @ReadOnly）简化调用。
引入代理中间件：对业务透明，扩展性好
部署独立代理层，由它解析 SQL 类型并自动路由。常用方案有：
- MySQL Router（Oracle 官方）：轻量，支持读写分离和故障转移，但功能较基础
- ProxySQL：高性能、规则灵活，可基于 SQL 模式、用户、响应时间做路由，支持自动剔除延迟过高的从库
- MaxScale：MariaDB 生态常用，支持复杂路由策略和语句重写
优势是业务无感，DBA 可集中管控；缺点是多一跳网络、需额外运维，且要注意代理自身高可用。
注意从库延迟与一致性边界
主从复制存在天然延迟（秒级甚至更高），盲目读从库可能读到旧数据：
- 登录态、订单状态、余额类场景，关键读必须走主库
- 可借助 GTID 或 semi-sync 复制缩短延迟，但不能完全消除
- 部分中间件（如 ProxySQL）支持“延迟阈值路由”：当从库延迟超过设定值（如 1 秒），自动将该会话后续读请求切回主库
负载均衡与健康检查不可少
多个从库之间需合理分担读流量，并及时下线异常节点：
- 代理层或客户端应定期执行 SHOW SLAVE STATUS 检查 Seconds_Behind_Master 和 IO/SQL 线程状态
- 避免将读请求发给已停止复制或延迟超标的从库
- 从库硬件配置建议不低于主库，否则容易成为瓶颈，反而拖累整体性能
不复杂但容易忽略。
